[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
+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
+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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org
+1 2016-03-15 14:05 GMT+01:00 Jean SIMARD <[email protected]>:
+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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
+1 Thanks, Alex On Tue, Mar 15, 2016 at 3:41 PM, Guillaume Delhumeau < [email protected]> wrote:
+1
2016-03-15 14:05 GMT+01:00 Jean SIMARD <[email protected]>:
+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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 Thanks, Eduard On Tue, Mar 15, 2016 at 3:42 PM, Alexandru Cotiuga < [email protected]> wrote:
+1
Thanks, Alex
On Tue, Mar 15, 2016 at 3:41 PM, Guillaume Delhumeau < [email protected]> wrote:
+1
2016-03-15 14:05 GMT+01:00 Jean SIMARD <[email protected]>:
+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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
+1 On Tue, Mar 15, 2016 at 4:23 PM, Eduard Moraru <[email protected]> wrote:
+1
Thanks, Eduard
On Tue, Mar 15, 2016 at 3:42 PM, Alexandru Cotiuga < [email protected]> wrote:
+1
Thanks, Alex
On Tue, Mar 15, 2016 at 3:41 PM, Guillaume Delhumeau < [email protected]> wrote:
+1
2016-03-15 14:05 GMT+01:00 Jean SIMARD <[email protected]>:
+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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 21 Mar 2016, at 16:57, Clemens Klein-Robbenhaar <[email protected]> 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
Hello Vincent, so, if I understand correctly, all rules about development from http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HGeneralD... 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 <[email protected]> wrote:
On 21 Mar 2016, at 16:57, Clemens Klein-Robbenhaar < [email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Anca,
On 24 Mar 2016, at 15:38, Anca Luca <[email protected]> wrote:
Hello Vincent,
so, if I understand correctly, all rules about development from http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HGeneralD... 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 <[email protected]> wrote:
On 21 Mar 2016, at 16:57, Clemens Klein-Robbenhaar < [email protected]> 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
On Thu, Mar 24, 2016 at 4:12 PM, Vincent Massol <[email protected]> wrote:
Hi Anca,
On 24 Mar 2016, at 15:38, Anca Luca <[email protected]> wrote:
Hello Vincent,
so, if I understand correctly, all rules about development from
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HGeneralD...
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/ApplicationDevelopmentBestPrac...
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 <[email protected]> wrote:
On 21 Mar 2016, at 16:57, Clemens Klein-Robbenhaar < [email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (9)
-
Alexandru Cotiuga -
Anca Luca -
Clemens Klein-Robbenhaar -
Eduard Moraru -
Guillaume Delhumeau -
Jean SIMARD -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol