Hi all,

This mail is about trying to improve how we work in xwiki-contrib and it 
supersedes the proposal I sent at http://markmail.org/message/qzc7ipiu6lazwbwr

Issues with current way of working in xwiki-contrib:

* Each project has a lead but this lead is MIA for a lot of extensions and it's 
a pain to maintain (I'm trying to do it but it's a pain)
* It doesn't make much sense to have a lead for an extension but then allowing 
anyone to commit on it without the lead's approval, nor allowing anyone to 
release new versions of that project without the lead participating to the 
discussion.
* Right now a committer can release a project using maven but doesn't have 
permissions to release it in jira nor creating a new version, causing 
synchronization issues
* The XWiki core committers are going to move a lot of non-core extensions to 
xwiki-contrib but there's no clear lead for a lot of those extensions since 
they were developed collaboratively and there's no notion of lead in the xwiki 
github organization. In practice the person from the XWiki core devs to work on 
a given extension varies over time (that’s how those extensions were built). 
It's not possible (and not a good idea) to give a long-time leadership to a 
single person.

Proposal:
=========

* XWiki Contrib is a community where extensions for XWiki can be developed and 
maintained together. It's a place that is of interest for people who want to 
share their sources and work collaboratively with others on them. If the intent 
is only to make an extension available to users of XWiki then it's enough to 
publish the binaries on extensions.xwiki.org (and put the souces anywhere they 
wish, including on the e.x.o page or on their github account if they have one).

* XWiki Contrib is defined by the xwiki-contrib github organization

* Anyone can request to join this community. This is the main difference with 
the xwiki github organization where you need to be voted in to become a 
committer. The main rationale is that making a mistake in the core has more 
impact than doing this in an extension. The second rationale is that this is an 
experiment to see if we can have a more vibrant community as a result of being 
more open, without loosing too much quality. 

* Once someone joins, he/she has commit access to all repositories in 
xwiki-contrib (and he/she's also added to a group on jira allowing him to 
create versions and releasing them.). The goal is to favor cross-pollination. 
In case this causes problem in the future, we can collaboratively decide to 
have stricter rules but it's a good experiment/principle to start as open as 
possible and close only if need be (the wiki principle ;)). So far, after 
several years of operations, there have been no incident in this way of working 
for xwiki-contrib that would have required restricting permissions.

* In order to simplify participating to any project in xwiki-contrib, the 
recommended development practices to follow are those found on dev.xwiki.org, 
i.e. the same as for the xwiki github organization. This prevents the issue 
that someone who wants to participate to more than 1 project needs to learn 
several dev practices; they're all the same. Now, these practices are best 
practices and the intent is that committers try to follow them as much as they 
can, in their capacity. Other committers reviewing code should be lenient in 
their comments and sentences like "You must do xxx" should be avoided and 
instead sentences like "When you have the time, it would be nice if you 
could...". OTOH, when a committer joins xwiki-contrib, he/she should understand 
that these best practices exist (and possibly spend some time reading them), 
and agree about following them as much as he/she can. Obviously anyone is free 
to discuss an existing rule and propose changing it or dropping it altogether.

* Anyone is free to release any project at any time. Recommendation is to send 
a release "[Proposal]" mail with a few lines explaining the intent to release 
on such date. If not possible for some constraint (time, neeed to release 
something else quickly that depends on a given extension, etc) then the release 
can be performed and some "[ANN]" mail sent later on to announce the release.

* Details on best practices (how to write one's pom.xml, how to document 
extensions on extensions.xwiki.org, etc) are found on contrib.xwiki.org

WDYT?

Thanks
-Vincent
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to