We need to progress on the Supported concept on xwiki.org.
Individual Support
Specifically one topic to discuss and agree on is that of individual support. For example I’ve just developed the Documentation Application extension and I want to indicate that “I’m supporting it, i.e. I’ll answer questions and do a best effort about fixing issues, at least for the time being”.
I reuse the existing Community organization but I create a support plan named after me, i.e. Vincent Massol.
Cons of 1):
A user is not really an organization name. It’s better to use “Community” for ex as an organization name.
Pros of 2):
Simpler (only 1 plan to create per individual who wants to support an extension)
Consistency, i.e. we won’t have tons of plans all named differently.
Cons of 2):
A user name is not really a plan name. But I feel it’s clear when it’s displayed in each extension. It’ll appear as “Community > Vincent Massol” (for ex).
So my preference goes to 2). WDYT?
Once we agree this point, I’ll ask on xwiki or in a forum post, everyone who wants to be a supporter of an extension, to register himself/herself on exo + add the info to the supported extensions.
Exo home page
I’m proposing to improve the home page:
Replace Recommended wording
Have a page that explains what Supported means (i.e. it’s up to the supporter to define what it means, the fact that it’s supposed to be a pledge that is renewed, etc).
Add a column in the LD to indicate the support org and plans (or create a link to another page listing that info if we think or find that there’ll be too many column).
I don’t understand this point. I don’t see why an individual could not be a supporter (and https://extensions.xwiki.org/xwiki/bin/view/Extension/Support/ actually mention “organizations or individuals”). What an individual clearly is not is a support plan
Well we will definitely have a ton of plans all named differently since you will get a plan per person
To improve consistency in the case of 1), I guess it should not be too hard to introduce some concept of plan templates, which would be suggested when you create a support plan.
My preference goes to 1). I’m -0 for 2) since it does not really make much sense semantically.
+1 in general, but I’m afraid that a new column might indeed means too many columns
BTW some related question: Why would someone take the time to put themself as supporter of an extension? Not only it takes time but it also puts pressure on them… Right now there are tons of extensions done by contributors/committers and they were not marked as recommended before even if they could have been (for ex, take https://extensions.xwiki.org/xwiki/bin/view/Extension/Script%20Component/).
I can think of 2 answers:
Because it’ll make the extension appear in the supported list which is nicer if you want to promote your work.
We could force it by adding a rule on contrib.xwiki.org that if you ask to create a contrib project, once you release it, you commit to supporting it for N months or 1 year at minimum. If not, why create it in contrib?
WDYT?
I feel that 1) is not enough. I think 2) could be interesting.
Right now it seems that the plans are specific to an org and thus can’t be reused by several orgs.
I’m not sure what’s best between a plan template or reusing a common plan. I have the feeling we need a common plan for individuals who are supporting an extension in their free time, as a best effort, and accepting questions using the xwiki.org forum.
That was my first reflex too, but then I though about maintainers choosing a common plan because it has a specific wording, and ending up with something they don’t agree with anymore when that plan wording is modified.
I’m not very familiar with the supported concepts. But I think both options have their use.
If the individual is independent (e.g., a consultant), they can use the first option.
If the individual is part of an organization (e.g., me as an XWiki committer), they can use the second option.
I’m not a fan of this as I think it would deter people from publishing their code. In my opinion, it is perfectly valid to publish an extension as open source on contrib that “works for me” without any intention of providing any form of support (or accepting any kind of contribution) just in the hope that it might be useful for somebody else, even if just as an inspiration. The burden of maintaining open source is already huge as people seem to already have lots of expectations on maintainers, let’s not make that worse by requiring an actual promise of free support (or setting up commercial support, which might also not be trivial/not wanted as the person might already have a full-time job that is incompatible with providing commercial support).
@MichaelHamann thx. Could you also answer the original question please?
The goal of xwiki-contrib is not to be a dump of open source projects that relate to XWiki. It’s to be an active place where to collaboratively develop extensions for XWiki.
Adding a project to contrib but not wanting to support it (for some time) is a red flag. It’s a project that will end up in xwiki-attic for sure and that will reduce the quality of xwiki-contrib in general (and of XWiki since users don’t make the distrinction - they find an extension, install it, if it doesn’t work, they think that XWiki is crap and move on). In that case, why not create it xwiki-attic directly if all you want is to share some code that you don’t want to support/work on. Then, if someone wants to continue developing it, it can become active again and be moved to contrib.
I understand what you’re saying but IMO it’s completely theoretical. In practice, I don’t know any person who asked for a repo on xwiki-contrib and who said they don’t want to “support” what they coded. Maybe your issue is with the word “support” and you’re afraid of what it can mean. The minimum support, and what I think most individuals would use as plan, is something like the following:
Answer questions on what’s been coded, on the forum. No specific delays in answers (best effort)
Best effort on fixing issues raised by users (and releasing new versions)
I’d say that this is already what we expect of anyone putting code on xwiki-contrib.
Can you list me one case where you think this could have been the case?
This is also why everyone can request commit rights on any contrib project.
Now, TBH, I didn’t say I want option 2). My thinking was that if we want to have community-supported entries, then I don’t see why someone would add himself/herself.
So, back to the original point (on which I’m curious to see your POV):
In that def, there was the concept of support but it was not a pledge. It was just the actual state of what was happening.
But we’re now moving to a support pledge instead.
So my worry is that we won’t have any devs wanting to put themselves as “official supporter” of an extension and thus even good extensions that we could promote will be hidden and not advertised…
Personally if I don’t have to do it, I don’t see why I’d mark myself as an official supporter of, say, the LaTeX extension, or the JIRA one, or the Markdown Syntax one, or any extension I’ve developed in the past. So these apps won’t appear in the highlighted extensions, unless someone else supports them (which happens to be the case for JIRA and Markdown for example as they’re marked as supported by XWiki SAS). And it’s a pity if the extensions work well and could benefit to our users.
It’s not clear to me why you, as an organization member, would need a dedicated support plan for you. Or otherwise put, why would the organization create a separate support plan for some / all of its members?
On my side I agree with @tmortagne that option 1 makes more sense, but it’s not clear to me what will happen with extensions having multiple maintainers. Do we create an organization specifically for that extension? How do you know who is a member of that dedicated organization?
I agree with Vincent here. There’s no point in bragging we have lots of extensions if only a few are maintained. I think it’s OK to add a rule on contrib.xwiki.org but I don’t know what’s the minimum time the extension contributor should pledge to maintain the extension. 1 year might be too much, but 3 months or so might be enough to get some feedback from users and fix trivial bugs that are discovered after the extension is published, when the code is still fresh in your head, and you haven’t moved to something else completely.
