[Proposal] Improving how we work in xwiki-contrib

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[Proposal] Improving how we work in xwiki-contrib

vmassol
Administrator
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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Improving how we work in xwiki-contrib

Marius Dumitru Florea
+1

Thanks,
Marius

On Tue, Mar 15, 2016 at 2:12 PM, Vincent Massol <[hidden email]> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Improving how we work in xwiki-contrib

Jean SIMARD
In reply to this post by vmassol
+1.

On 15/03/2016 13:12, Vincent Massol 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>

--
Jean Simard
[hidden email]
Research engineer at XWiki SAS
http://www.xwiki.com
Committer on the XWiki.org project
http://www.xwiki.org
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Improving how we work in xwiki-contrib

Guillaume Delhumeau
+1

2016-03-15 14:05 GMT+01:00 Jean SIMARD <[hidden email]>:

> +1.
>
> On 15/03/2016 13:12, Vincent Massol 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
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
> --
> Jean Simard
> [hidden email]
> Research engineer at XWiki SAS
> http://www.xwiki.com
> Committer on the XWiki.org project
> http://www.xwiki.org
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Improving how we work in xwiki-contrib

Alex Cotiugă
+1

Thanks,
Alex

On Tue, Mar 15, 2016 at 3:41 PM, Guillaume Delhumeau <
[hidden email]> wrote:

> +1
>
> 2016-03-15 14:05 GMT+01:00 Jean SIMARD <[hidden email]>:
>
> > +1.
> >
> > On 15/03/2016 13:12, Vincent Massol 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
> > > [hidden email]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> >
> > --
> > Jean Simard
> > [hidden email]
> > Research engineer at XWiki SAS
> > http://www.xwiki.com
> > Committer on the XWiki.org project
> > http://www.xwiki.org
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
>
>
> --
> Guillaume Delhumeau ([hidden email])
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Improving how we work in xwiki-contrib

Eduard Moraru
+1

Thanks,
Eduard

On Tue, Mar 15, 2016 at 3:42 PM, Alexandru Cotiuga <
[hidden email]> wrote:

> +1
>
> Thanks,
> Alex
>
> On Tue, Mar 15, 2016 at 3:41 PM, Guillaume Delhumeau <
> [hidden email]> wrote:
>
> > +1
> >
> > 2016-03-15 14:05 GMT+01:00 Jean SIMARD <[hidden email]>:
> >
> > > +1.
> > >
> > > On 15/03/2016 13:12, Vincent Massol 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
> > > > [hidden email]
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > >
> > >
> > > --
> > > Jean Simard
> > > [hidden email]
> > > Research engineer at XWiki SAS
> > > http://www.xwiki.com
> > > Committer on the XWiki.org project
> > > http://www.xwiki.org
> > > _______________________________________________
> > > devs mailing list
> > > [hidden email]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> >
> >
> >
> > --
> > Guillaume Delhumeau ([hidden email])
> > Research & Development Engineer at XWiki SAS
> > Committer on the XWiki.org project
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Improving how we work in xwiki-contrib

Thomas Mortagne
Administrator
+1

On Tue, Mar 15, 2016 at 4:23 PM, Eduard Moraru <[hidden email]> wrote:

> +1
>
> Thanks,
> Eduard
>
> On Tue, Mar 15, 2016 at 3:42 PM, Alexandru Cotiuga <
> [hidden email]> wrote:
>
>> +1
>>
>> Thanks,
>> Alex
>>
>> On Tue, Mar 15, 2016 at 3:41 PM, Guillaume Delhumeau <
>> [hidden email]> wrote:
>>
>> > +1
>> >
>> > 2016-03-15 14:05 GMT+01:00 Jean SIMARD <[hidden email]>:
>> >
>> > > +1.
>> > >
>> > > On 15/03/2016 13:12, Vincent Massol 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
>> > > > [hidden email]
>> > > > http://lists.xwiki.org/mailman/listinfo/devs
>> > > >
>> > >
>> > > --
>> > > Jean Simard
>> > > [hidden email]
>> > > Research engineer at XWiki SAS
>> > > http://www.xwiki.com
>> > > Committer on the XWiki.org project
>> > > http://www.xwiki.org
>> > > _______________________________________________
>> > > devs mailing list
>> > > [hidden email]
>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> > >
>> >
>> >
>> >
>> > --
>> > Guillaume Delhumeau ([hidden email])
>> > Research & Development Engineer at XWiki SAS
>> > Committer on the XWiki.org project
>> > _______________________________________________
>> > devs mailing list
>> > [hidden email]
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Thomas Mortagne
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Improving how we work in xwiki-contrib

Clemens Klein-Robbenhaar
In reply to this post by vmassol
+1

 I spend some time about nitpicking the "the recommended development practices to follow are those found on dev.xwiki.org", because it is not exactly obvious which parts on dev.xwiki.org are development practices and this apply and which ones are not
(e.g. http://dev.xwiki.org/xwiki/bin/view/Community/Governance does not apply, but e.g.Code style probably does, and then some parts of http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices apply, and some not - e.g "Release Manager" is explicitly about XWiki core, but the general infra structure and coding advice applies ...

 ... but then I decided to forget about it because a bit of common sense allows this to sort out by itself; the important thing is be nice, and a bit lore lenient and relaxed no new contributors, so they feel welcome :)

Clemens

----- Ursprüngliche Nachricht -----
Von: Vincent Massol
Am:  Tuesday, 15.03.2016, 13:12
An: Xwiki Developers
Betreff: [xwiki-devs] [Proposal] Improving how we work in xwiki-contrib


> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Improving how we work in xwiki-contrib

vmassol
Administrator

> On 21 Mar 2016, at 16:57, Clemens Klein-Robbenhaar <[hidden email]> wrote:
>
> +1
>
> I spend some time about nitpicking the "the recommended development practices to follow are those found on dev.xwiki.org", because it is not exactly obvious which parts on dev.xwiki.org are development practices and this apply and which ones are not
> (e.g. http://dev.xwiki.org/xwiki/bin/view/Community/Governance does not apply, but e.g.Code style probably does, and then some parts of http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices apply, and some not - e.g "Release Manager" is explicitly about XWiki core, but the general infra structure and coding advice applies …

Actually the goal is to make it all apply in the future by rephrasing the places that currently only make sense for the xwiki github org. Note that http://dev.xwiki.org/xwiki/bin/view/Community/Governance does apply (a project on xwiki-contrib also has some web pages on xwiki.org) :)

> ... but then I decided to forget about it because a bit of common sense allows this to sort out by itself; the important thing is be nice, and a bit lore lenient and relaxed no new contributors, so they feel welcome :)

Yup :)

Thanks
-Vincent

> Clemens
>
> ----- Ursprüngliche Nachricht -----
> Von: Vincent Massol
> Am:  Tuesday, 15.03.2016, 13:12
> An: Xwiki Developers
> Betreff: [xwiki-devs] [Proposal] Improving how we work in xwiki-contrib
>
>
>> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Improving how we work in xwiki-contrib

Anca Luca
Hello Vincent,

so, if I understand correctly, all rules about development from
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HGeneralDevelopmentFlow
and http://dev.xwiki.org/xwiki/bin/view/Community/Committership and
potentially other places will now apply to the community XWiki Contrib as
well, except for the releases, for which a rule specific to contrib was
created.
I think it would be a good idea to prepare a sort of a cheat sheet or
"short version" of these rules, for people to easily read and understand
how to work with the new concept of community XWiki Contrib. This could
also work as a guide for users that are already extension developers, and
they need to quickly understand what changes for them with this new
organisation.

Thanks,
Anca


On Mon, Mar 21, 2016 at 5:20 PM, Vincent Massol <[hidden email]> wrote:

>
> > On 21 Mar 2016, at 16:57, Clemens Klein-Robbenhaar <
> [hidden email]> wrote:
> >
> > +1
> >
> > I spend some time about nitpicking the "the recommended development
> practices to follow are those found on dev.xwiki.org", because it is not
> exactly obvious which parts on dev.xwiki.org are development practices
> and this apply and which ones are not
> > (e.g. http://dev.xwiki.org/xwiki/bin/view/Community/Governance does not
> apply, but e.g.Code style probably does, and then some parts of
> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices apply,
> and some not - e.g "Release Manager" is explicitly about XWiki core, but
> the general infra structure and coding advice applies …
>
> Actually the goal is to make it all apply in the future by rephrasing the
> places that currently only make sense for the xwiki github org. Note that
> http://dev.xwiki.org/xwiki/bin/view/Community/Governance does apply (a
> project on xwiki-contrib also has some web pages on xwiki.org) :)
>
> > ... but then I decided to forget about it because a bit of common sense
> allows this to sort out by itself; the important thing is be nice, and a
> bit lore lenient and relaxed no new contributors, so they feel welcome :)
>
> Yup :)
>
> Thanks
> -Vincent
>
> > Clemens
> >
> > ----- Ursprüngliche Nachricht -----
> > Von: Vincent Massol
> > Am:  Tuesday, 15.03.2016, 13:12
> > An: Xwiki Developers
> > Betreff: [xwiki-devs] [Proposal] Improving how we work in xwiki-contrib
> >
> >
> >> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Improving how we work in xwiki-contrib

vmassol
Administrator
Hi Anca,

> On 24 Mar 2016, at 15:38, Anca Luca <[hidden email]> wrote:
>
> Hello Vincent,
>
> so, if I understand correctly, all rules about development from
> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HGeneralDevelopmentFlow
> and http://dev.xwiki.org/xwiki/bin/view/Community/Committership and
> potentially other places will now apply to the community XWiki Contrib as
> well, except for the releases, for which a rule specific to contrib was
> created.

All pages from dev.xwiki.org apply, not just the ones you mentioned. The full dev.xwiki.org is about development practices for the xwiki open source project and the idea is to have a single way to do development for the XWiki open source project.

To give some examples:
* Hall of fame page applies
* Governance page for xwiki.org applies
* Building page applies
* etc

However it’s possible that the wording we have in some of those places are not good for contrib because they were written before we decided to fold in contrib. Thus we should rewrite those few places where the wording is awkward. I can do it if someone points me to them.

> I think it would be a good idea to prepare a sort of a cheat sheet or
> "short version" of these rules, for people to easily read and understand
> how to work with the new concept of community XWiki Contrib. This could
> also work as a guide for users that are already extension developers, and
> they need to quickly understand what changes for them with this new
> organisation.

Sure I agree in theory, but:
1) I don’t have the time (it’s a huge task)
2) dev.xwiki.org is already a cheat sheet. There’s no extra stuff there. It contains the bare minimum already
3) if we were to do this it would a major pain to maintain since we’d need to keep the 2 versions in sync and there’s really not enough people helping on xwiki.org to do this.

Thanks
-Vincent

> Thanks,
> Anca
>
>
> On Mon, Mar 21, 2016 at 5:20 PM, Vincent Massol <[hidden email]> wrote:
>
>>
>>> On 21 Mar 2016, at 16:57, Clemens Klein-Robbenhaar <
>> [hidden email]> wrote:
>>>
>>> +1
>>>
>>> I spend some time about nitpicking the "the recommended development
>> practices to follow are those found on dev.xwiki.org", because it is not
>> exactly obvious which parts on dev.xwiki.org are development practices
>> and this apply and which ones are not
>>> (e.g. http://dev.xwiki.org/xwiki/bin/view/Community/Governance does not
>> apply, but e.g.Code style probably does, and then some parts of
>> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices apply,
>> and some not - e.g "Release Manager" is explicitly about XWiki core, but
>> the general infra structure and coding advice applies …
>>
>> Actually the goal is to make it all apply in the future by rephrasing the
>> places that currently only make sense for the xwiki github org. Note that
>> http://dev.xwiki.org/xwiki/bin/view/Community/Governance does apply (a
>> project on xwiki-contrib also has some web pages on xwiki.org) :)
>>
>>> ... but then I decided to forget about it because a bit of common sense
>> allows this to sort out by itself; the important thing is be nice, and a
>> bit lore lenient and relaxed no new contributors, so they feel welcome :)
>>
>> Yup :)
>>
>> Thanks
>> -Vincent
>>
>>> Clemens
>>>
>>> ----- Ursprüngliche Nachricht -----
>>> Von: Vincent Massol
>>> Am:  Tuesday, 15.03.2016, 13:12
>>> An: Xwiki Developers
>>> Betreff: [xwiki-devs] [Proposal] Improving how we work in xwiki-contrib
>>>
>>>
>>>> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [Proposal] Improving how we work in xwiki-contrib

Anca Luca
On Thu, Mar 24, 2016 at 4:12 PM, Vincent Massol <[hidden email]> wrote:

> Hi Anca,
>
> > On 24 Mar 2016, at 15:38, Anca Luca <[hidden email]> wrote:
> >
> > Hello Vincent,
> >
> > so, if I understand correctly, all rules about development from
> >
> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HGeneralDevelopmentFlow
> > and http://dev.xwiki.org/xwiki/bin/view/Community/Committership and
> > potentially other places will now apply to the community XWiki Contrib as
> > well, except for the releases, for which a rule specific to contrib was
> > created.
>
> All pages from dev.xwiki.org apply, not just the ones you mentioned. The
> full dev.xwiki.org is about development practices for the xwiki open
> source project and the idea is to have a single way to do development for
> the XWiki open source project.
>
> To give some examples:
> * Hall of fame page applies
> * Governance page for xwiki.org applies
> * Building page applies
> * etc


Actually, I was thinking about a very precise situation: changing the
minimal compatible version of XWiki for an extension. There are a bunch of
rules on dev.xwiki.org which cover this case (e.g. (1) or (2)).
However, I am worried that it will be difficult for contributors to
discover these rules and understand that they apply to their case, since
there is a lot of documentation and it takes time and experience to
understand this documentation properly. Since my assumption is that the
expectation from a contributor is to be able to be a contributor while not
being "full time" in the community, I made the proposal about the cheat
sheet with examples.
Also, since some of the generic dev.xwiki.org rules won't be followed
because leniency and flexibility (e.g. (2) is not even followed by the apps
we made as part of platform), I imagine that contributors could have a
wrong evaluation about the importance of a certain rule for extensions
(e.g. keeping a low version of compatibility is important for extensions,
in my opinion, but I am not expecting everybody to understand it in the
same way).

So, to try to make it short, do we have a plan to handle this kind of
things to make it easy to work together on extensions?
("Easy" compared to the xwiki.org community, for which being a committer
requires a certain time spent in the community, deep understanding of
rules, trust in the judgement, a certain committment).

Thank you for reading,
Anca

(1) "In general votes should be sent in case of big changes (whether it's
about code or about processes or people)." from
http://dev.xwiki.org/xwiki/bin/view/Community/Committership#HVoting
(2) "In your POM always try to depend on the oldest version of
commons/rendering/platform dependencies for which your code works. At
least, ensure that your Applications works on the latest LTS version of
XWiki. This will allow the largest number of users to use your
application." from
http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPractices


>
> However it’s possible that the wording we have in some of those places are
> not good for contrib because they were written before we decided to fold in
> contrib. Thus we should rewrite those few places where the wording is
> awkward. I can do it if someone points me to them.
>
> > I think it would be a good idea to prepare a sort of a cheat sheet or
> > "short version" of these rules, for people to easily read and understand
> > how to work with the new concept of community XWiki Contrib. This could
> > also work as a guide for users that are already extension developers, and
> > they need to quickly understand what changes for them with this new
> > organisation.
>
> Sure I agree in theory, but:
> 1) I don’t have the time (it’s a huge task)
> 2) dev.xwiki.org is already a cheat sheet. There’s no extra stuff there.
> It contains the bare minimum already
> 3) if we were to do this it would a major pain to maintain since we’d need
> to keep the 2 versions in sync and there’s really not enough people helping
> on xwiki.org to do this.
>
> Thanks
> -Vincent
>
> > Thanks,
> > Anca
> >
> >
> > On Mon, Mar 21, 2016 at 5:20 PM, Vincent Massol <[hidden email]>
> wrote:
> >
> >>
> >>> On 21 Mar 2016, at 16:57, Clemens Klein-Robbenhaar <
> >> [hidden email]> wrote:
> >>>
> >>> +1
> >>>
> >>> I spend some time about nitpicking the "the recommended development
> >> practices to follow are those found on dev.xwiki.org", because it is
> not
> >> exactly obvious which parts on dev.xwiki.org are development practices
> >> and this apply and which ones are not
> >>> (e.g. http://dev.xwiki.org/xwiki/bin/view/Community/Governance does
> not
> >> apply, but e.g.Code style probably does, and then some parts of
> >> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices
> apply,
> >> and some not - e.g "Release Manager" is explicitly about XWiki core, but
> >> the general infra structure and coding advice applies …
> >>
> >> Actually the goal is to make it all apply in the future by rephrasing
> the
> >> places that currently only make sense for the xwiki github org. Note
> that
> >> http://dev.xwiki.org/xwiki/bin/view/Community/Governance does apply (a
> >> project on xwiki-contrib also has some web pages on xwiki.org) :)
> >>
> >>> ... but then I decided to forget about it because a bit of common sense
> >> allows this to sort out by itself; the important thing is be nice, and a
> >> bit lore lenient and relaxed no new contributors, so they feel welcome
> :)
> >>
> >> Yup :)
> >>
> >> Thanks
> >> -Vincent
> >>
> >>> Clemens
> >>>
> >>> ----- Ursprüngliche Nachricht -----
> >>> Von: Vincent Massol
> >>> Am:  Tuesday, 15.03.2016, 13:12
> >>> An: Xwiki Developers
> >>> Betreff: [xwiki-devs] [Proposal] Improving how we work in xwiki-contrib
> >>>
> >>>
> >>>> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs