15 Mar
2016
15 Mar
'16
1:12 p.m.
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
15 Mar
15 Mar
1:45 p.m.
+1
Thanks,
Marius
On Tue, Mar 15, 2016 at 2:12 PM, Vincent Massol <vincent(a)massol.net> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:05 p.m.
+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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jean Simard
jean.simard(a)xwiki.com
Research engineer at XWiki SAS
http://www.xwiki.com
Committer on the XWiki.org project
http://www.xwiki.org
2:41 p.m.
+1
2016-03-15 14:05 GMT+01:00 Jean SIMARD <jean.simard(a)xwiki.com>om>:
+1.
On 15/03/2016 13:12, Vincent Massol wrote:
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jean Simard
jean.simard(a)xwiki.com
Research engineer at XWiki SAS
http://www.xwiki.com
Committer on the XWiki.org project
http://www.xwiki.org
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:42 p.m.
+1
Thanks,
Alex
On Tue, Mar 15, 2016 at 3:41 PM, Guillaume Delhumeau <
guillaume.delhumeau(a)xwiki.com> wrote:
+1
2016-03-15 14:05 GMT+01:00 Jean SIMARD <jean.simard(a)xwiki.com>om>:
+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
causing
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, synchronization issues
notion
* 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 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.
others
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 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.
be
* 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 (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.
to
* 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 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.
intent
* Anyone is free to release any project at any time. Recommendation is
to send a
release "[Proposal]" mail with a few lines explaining the 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
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jean Simard
jean.simard(a)xwiki.com
Research engineer at XWiki SAS
http://www.xwiki.com
Committer on the XWiki.org project
http://www.xwiki.org
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:23 p.m.
+1
Thanks,
Eduard
On Tue, Mar 15, 2016 at 3:42 PM, Alexandru Cotiuga <
alexandru.cotiuga(a)xwiki.com> wrote:
+1
Thanks,
Alex
On Tue, Mar 15, 2016 at 3:41 PM, Guillaume Delhumeau <
guillaume.delhumeau(a)xwiki.com> wrote:
those
the
of
has
is
neeed
contrib.xwiki.org
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
+1
2016-03-15 14:05 GMT+01:00 Jean SIMARD <jean.simard(a)xwiki.com>om>:
extensions
+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 > 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.
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 * 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,
extensions since they were developed collaboratively and there's no
notion
> of lead in the xwiki github organization. In practice the person from > 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.
others
> on them. If the intent is only to make an extension available to users
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 > 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 > 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
have
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 > 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 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, > 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
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jean Simard
jean.simard(a)xwiki.com
Research engineer at XWiki SAS
http://www.xwiki.com
Committer on the XWiki.org project
http://www.xwiki.org
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:52 p.m.
+1
On Tue, Mar 15, 2016 at 4:23 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
+1
Thanks,
Eduard
On Tue, Mar 15, 2016 at 3:42 PM, Alexandru Cotiuga <
alexandru.cotiuga(a)xwiki.com> wrote:
--
Thomas Mortagne
+1
Thanks,
Alex
On Tue, Mar 15, 2016 at 3:41 PM, Guillaume Delhumeau <
guillaume.delhumeau(a)xwiki.com> wrote:
those
the
of
has
is
neeed
contrib.xwiki.org
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs +1
2016-03-15 14:05 GMT+01:00 Jean SIMARD <jean.simard(a)xwiki.com>om>:
extensions
+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 > 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
extensions since they were developed collaboratively and there's no
notion
> of lead in the xwiki github organization. In practice the person from > 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 > 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 > 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
have
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 > 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 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, > 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 >
> WDYT?
>
> Thanks
> -Vincent
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Jean Simard
jean.simard(a)xwiki.com
Research engineer at XWiki SAS
http://www.xwiki.com
Committer on the XWiki.org project
http://www.xwiki.org
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
21 Mar
21 Mar
4:57 p.m.
+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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:20 p.m.
On 21 Mar 2016, at 16:57, Clemens Klein-Robbenhaar
<c.robbenhaar(a)espresto.com> 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
24 Mar
24 Mar
3:38 p.m.
Hello Vincent,
so, if I understand correctly, all rules about development from
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HGeneral…
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 <vincent(a)massol.net> wrote:
On 21 Mar 2016, at 16:57, Clemens
Klein-Robbenhaar <
c.robbenhaar(a)espresto.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:12 p.m.
Hi Anca,
On 24 Mar 2016, at 15:38, Anca Luca
<lucaa(a)xwiki.com> wrote:
Hello Vincent,
so, if I understand correctly, all rules about development from
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HGeneral…
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 <vincent(a)massol.net> wrote:
>
>> On 21 Mar 2016, at 16:57, Clemens Klein-Robbenhaar <
> c.robbenhaar(a)espresto.com> 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
5:28 p.m.
On Thu, Mar 24, 2016 at 4:12 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi Anca,
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/ApplicationDevelopmentBestPra…
On 24 Mar 2016, at 15:38, Anca Luca
<lucaa(a)xwiki.com> wrote:
Hello Vincent,
so, if I understand correctly, all rules about development from
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HGeneral…
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 <vincent(a)massol.net>
wrote:
>
>> On 21 Mar 2016, at 16:57, Clemens Klein-Robbenhaar <
> c.robbenhaar(a)espresto.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3508
days inactive
3517
days old
11 comments
9 participants
participants (9)
-
Alexandru Cotiuga -
Anca Luca -
Clemens Klein-Robbenhaar -
Eduard Moraru -
Guillaume Delhumeau -
Jean SIMARD -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol