+1 Thanks, Marius
On Tue, Mar 15, 2016 at 2:12 PM, Vincent Massol <[email protected]> wrote: > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
