Re: [xwiki-devs] [Brainstorming] Issue tracking for xwiki-contrib projects

7 Oct 2014

Speaking of centralized view of all issues, GitHub just released this:
https://github.com/blog/1901-managing-issues-and-pull-requests-across-repos…

On Wed, Oct 1, 2014 at 7:42 AM, Eduard Moraru &lt;enygma2002(a)gmail.com&gt; wrote:

...
  On Wed, Oct 1, 2014 at 11:22 AM, Thomas Mortagne <
 thomas.mortagne(a)xwiki.com&gt;
 wrote:

  On Wed, Oct 1, 2014 at 10:15 AM, Marius Dumitru
Florea
 &lt;mariusdumitru.florea(a)xwiki.com&gt; wrote:
  On Wed, Oct 1, 2014 at 10:00 AM, Eduard Moraru
&lt;enygma2002(a)gmail.com&gt;  wrote:
 > As mentioned to Vincent in a previous private
discussion, perhaps a  great
 > improvement more or less related to this
topic, if we are to keep
> recommending/forcing jira for contrib projects, would be to use some  jira
 >> plugin that allows logging in with GitHub credentials.
 >>
 >> Would be nice if we would have such an extension for xwiki.org as  well
  so
 > that a developer can seamlessly integrate
into the XWiki ecosystem  without
 > creating 3 accounts:
> - 1 jira account 
 > - 1 xwiki.org account (for e.x.o) 
 As far as I understand github support OAuth so it's pretty much about
 reuse/improve

 http://extensions.xwiki.org/xwiki/bin/view/Extension/Social+Login+Applicati…
  on xwiki.org I guess (and maybe add a filter
based on
 https://github.com/orgs/xwiki-contrib/people).

 Or maybe we could ditch the filter and just make xwiki.org GitHub friendly
 overall. IMO, it should not only be about contrib users, but about anyone
 willing to contribute, in any way.

 BTW, I just remembered/re-noticed that we need yet another (4th) account
 for l10n.xwiki.org. This too could benefit from the OAuth stuff.

 Thanks,
 Eduard

   - 1 nexus
account
 ... when he already has a "developer" account on GitHub.

 WDYT? 
 That would be awesome!

 Thanks,
 Marius

>
> Thanks,
> Eduard
>
> On Mon, Sep 29, 2014 at 12:49 PM, vincent(a)massol.net < 
vincent(a)massol.net&gt;
 >> wrote:
 >>
 >>>
 >>>
 >>>
 >>> On 29 Sep 2014 at 11:24:19, Caleb James DeLisle (cjd(a)cjdns.fr 
(mailto:
  >>
cjd(a)cjdns.fr)) wrote:
>>
>> > To be clear, I think both decisions are valid in their own time.
>> > Someone who always picks A is flitting from one tool to another, 
never
 >> > getting any work done, someone who
always picks B is stuck in a  previous
 >>> > century.
 >>> > The question is not If but When.
 >>>
 >>> What’s below is slightly off topic since this is sliding away from 
the
  >>> issue tracker to use for
xwiki-contrib. OTOH since I said I believe  we
  >>> should use the same tool for both,
it’s not so off topic ;)
 >>>
 >>> To answer Caleb on "The question is not If but When”, this is true
 for
  >>> everything... Of course GitHub will
go away in due time (and so will  GH
  >>> issues) and of course the XWiki
project will move away from Git when  a
  next
 >> and better SCM appears in a few years ;)
(as we did move from CVS to
>> Subversion to Git already). The same will happen for JIRA but usually  you
 >> only move when there’s a
compelling-enough reason since the cost of  moving
 >> is pretty high in general.
>>
>> ATM in term of issue tracker there are really only 2 real contenders  (ie
 >> with enough features for us) that I know
of that could be used by the  XWiki
 >> project:
>> - JIRA
>> - youtrack
>>
>> There’s also Mantis that I don’t really know about but from the few
>> screenshots I’ve seen it doesn’t look as nice as either JIRA or  youtrack.
 >>
>> Youtrack was missing quite a lot of features compared to jira when I
>> evaluated it some years ago but I’ve just noticed it’s coming on par  now,
 >> especially with
http://www.jetbrains.com/youtrack/nextversion/
>>
>> Thanks
>> -Vincent
>>
>> > On 09/29/2014 10:23 AM, Jeremie BOUSQUET wrote:
>> > > Funny to see this kind of discussions in xwiki or another OSS
>> community,
>> > > after seeing them during my work so many times :)
>> > > Seems when it comes to issue tracking, always the same arguments 
and
 >> > > counter-arguments come and go.
>> > > Funny also to see that after all the web 2.0 buzz, the rich web
>> interfaces,
>> > > a simple issue form can frighten so many people ;-)
>> > > Funny also to see all these discussions for something as
"simple"  as an
 >> > > issue tracker. Basically,
it's just filling a table, through some  forms
 >>> > > containing some basic fields (title, description, version...).
 Even
  >>> with
 >>> > > all fancy features as in Jira, it's really less complex to use
 than
  >>> most
 >>> > > source code management tools.
 >>> > >
 >>> > > If new devs "come and go", you could also say that as
 contributors
  they
 >> > > will also "come and
go". Said differently, what would you be  willing to
 >> > > loose, knowing that you may let
it go for people that may... not  stay
 >> very
>> > > long ? And with recent discussions about moving some contributed
>> extensions
>> > > closer to the core xwiki maintainers, having different tools may 
have
 >>> more
 >>> > > impacts.
 >>> > >
 >>> > > I'm also from category "A" as defined by Vincent,
but I must  admit
  >>> that all
 >>> > > arguments seem valid, and I may be wrong thinking that - these
 are
  >>> > > never-ending discussions.
Usually it ends up with people trying  to
  put
 >> in
>> > > place automatic synchronizations between jira and github, to 
satisfy
 >>> > > everyone - more maintenance and more headaches :-)
 >>> > >
 >>> > > In my work we used for a long time another issue tracking tool,
 and
  >>
forms
>> > > used to create new issues counted maybe 10 times more fields than
 what
 >> you
>> > > have in JIRA (counting the optional fields).
>> > > As a modest extension contributor on xwiki, I was so glad to find
 JIRA
 >> - I
>> > > always wished I could use it for my work, instead of the plethora
 of
 >> > > (no-so-good) tools we tried ...
But I understand your points.
>> > >
>> > > I'd say that it's a difficult choice around contributions, but
if  at
 >> least
>> > > the xwiki team is satisfied globally with the jira issue tracking
 tool
 >>> for
 >>> > > themselves, it's already something valuable as it's not
always  the
  >>
case.
>> > >
>> > >
>> > >
>> > > 2014-09-29 9:32 GMT+02:00 Caleb James DeLisle :
>> > >
>> > >> Nice summary of the technical costs/benefits.
>> > >> What I think is missing is compatibility between XWiki project
 and the
 >> > >> developer community.
>> > >>
>> > >> For good or for ill, kids these days use github.
>> > >>
>> > >> The days of svn, jira and tight knit developer communities are
 gone,
 >> devs
>> > >> are their own
>> > >> free agents, they come and go as they please and asking them to
 learn
 >> a
>> > >> new bugtracker
>> > >> is like asking them to learn a new language.
>> > >>
>> > >> It's hard to accept that #1 jira has no future in OSS and #2 we
 are
 >>> using
 >>> > >> jira for OSS,
 >>> > >> but the world is always changing, anything which has reached
 >>> "stability"
 >>> > >> has begun to
 >>> > >> lose the market and a bit of cognitive dissidence is the cost
of
 >>> avoiding
 >>> > >> delusions.
 >>> > >>
 >>> > >>
 >>> > >> Not that it matters much our decision today, if we keep jira
 we'll
  >>
just
>> > >> end up having
>> > >> this conversation again in a year :)
>> > >>
>> > >> Thanks,
>> > >> Caleb
>> > >>
>> > >>
>> > >> On 09/28/2014 06:36 PM, vincent(a)massol.net wrote:
>> > >>> Hi everyone,
>> > >>>
>> > >>> I’ve read again the full thread and here are some thoughts I
 have:
 >> > >>>
>> > >>> 1) First, I’d like to state again that when someone wishes to
 join
 >>> > >> xwiki-contrib it’s not a neutral act. It means: “I’d like to
 join
  a
 >> > >> community, develop my
extension collaboratively with others and  abide
 >> by
>> > >> the project rules”. It’s thus normal that we set up some rules
 even
 >> for
>> > >> xwiki-contrib (these rules can be at code level or at the level
 of the
 >> > >> tools used to develop the
software). They are needed because as  soon
 >> as the
>> > >> code is developed by more than 1 person it’s required. If the
 person
 >> > >> doesn’t want to be bothered
and is not ready to follow those  rules,
 >> it’s
>> > >> fine, they don’t need to be in xwiki-contrib because they can
 still
 >> make
>> > >> their extension have the same visibility as others simply by
>> publishing
>> > >> them on http://extensions.xwiki.org (e.x.o). That said, of 
course, we
 >> > >> should still provide
development tools that are the simplest  possible.
 >>> > >> Actually this should be true also when developing XWiki “core”
 so
  in
 >> > >> general I don’t see much
differences between b
>> > >> o
>> > >> th. If it’s hard for contributors it’s also hard for core 
developers
 >> and
>> > >> we might as well fix the issue for everyone. Last point is
>> maintenance:
>> > >> lots of people (including some committers) don’t see the 
maintenance
 >> > >> involved (cleaning up
issues, maintaining the infrastructure -
>> monitoring,
>> > >> restarts, upgrades of tools, ensuring the quality of the 
extensions,
 >> fixing
>> > >> documentation mistakes/missing items on e.x.o, etc). In practice
>> there are
>> > >> very few committers who do this maintenance and we shouldn’t
>> overburden
>> > >> them either. Offering too many choices means more burden on
>> > >> infrastructure/maintenance. This is why BTW that forges are 
usually
 >> > >> reticent to offer more than
one tool to use for each domain.
>> > >>>
>> > >>> 2) Seems we have 2 categories of people on this thread:
>> > >>> A- those who consider that a single place for issues with the
>> ability to
>> > >> have a global dashboard/search feature is key
>> > >>> B- those who consider that it’s more important to offer freedom
 of
 >> issue
>> > >> tracker choice to contributors than the single place to 
search/view
 >> all
>> > >> issues
>> > >>>
>> > >>> Personally I’m more more in the category A because:
>> > >>> - it means less maintenance
>> > >>> - I believe global search and a global place for issues is
 important
 >> > >>> - I believe JIRA can be
configured to be as simple as GH if  that’s
 >> what
>> > >> we want (more below)
>> > >>>
>> > >>> 3) I agree that we should try to make our issue creation 
experience
 >>> as
 >>> > >> simple as possible (some ideas below)
 >>> > >>>
 >>> > >>> 4) Note: If we were to allow using GH issues, we would
also  need
  to
 >>> > >> develop a {{ghissue}} macro for release notes on e.x.o similar
 to
  the
 >> > >> {{jira}} macro. Not a big
deal but would need to be done.
>> > >>>
>> > >>> 5) Sergiu mentioned: “ Supplementing Jean's answer,
creating a  Jira
 >> > >> issue is a lot of work,
having to decide what version is  affected, the
 >> > >> relevant components,
labels, environment, priority... A GitHub  issue
 >> can be
>> > >> just a title, and it takes seconds to create.”.
>> > >>>
>> > >>> I think this has more to do with how we setup our JIRA:
>> > >>> - "having to decide what version is affected”. This is
always  needed
 >>> for
 >>> > >> bugs, be it on JIRA or on GH issues. Also note that on JIRA
the
 >>> “affects
 >>> > >> version” field is NOT mandatory. We have a best practice of
 always
  >>
filling
>> > >> it ourselves but we could change that rule and decide that we
 should
 >>> fill
 >>> > >> it only for bugs for example.
 >>> > >>> - "the relevant components”. Again this is optional
in JIRA  too.
  >>
> >> Actually now that JIRA makes it easy in the UI to edit fields 
(without
 >>> > >> having to go in edit mode) we could make all optional field
not  be
  >>
visible
>> > >> in the Basic Issue Creation Field Scheme (what you see when you
 click
 >> on
>> > >> “Create Issue”). The only possible downside is that we will 
receive
 >>> more
 >>> > >> mails.
 >>> > >>> - “labels, environment”. Again this is optional too in
JIRA.  BTW
  in
 >> your
>> > >> link (https://github.com/phenotips/phenotips/issues/1116) you
 seem to
 >> > >> also use that on GH issues
so I don’t see the difference.
>> > >>> - “priority” is also optional.
>> > >>> - "A GitHub issue can be just a title, and it takes
seconds to
>> create”.
>> > >> And it’s exactly the same for a JIRA issue. All you need to fill
 in
 >> is the
>> > >> “summary" field :)
>> > >>>
>> > >>> In conclusion: this is not a differentiator between JIRA and
GH
>> issues.
>> > >> If we think it’s scary for a user to see the optional fields in
 the
 >> Basic
>> > >> Issue Creation Field Scheme, then let’s remove them from that
 screen
 >> now.
>> > >>>
>> > >>> 6) Regarding traceability by putting issue reference in commits
 it’s
 >> for
>> > >> us to decide whether we want this as a best practice or not. It
 does’t
 >>> > >> depend on the issue tracker we use. For example
 >>> > >> https://github.com/phenotips/phenotips/issues/1116 shows that
 it
  also
 >>> > >> exists in GH issues. Personally I think that it’s part of the
 best
  >>> > >> practices we should
keep in the XWiki ecosystem but it could be
 >>> discussed.
 >>> > >> Jean feels it a burden apparently. However I don’t know how
 often
  >>
Jean has
>> > >> had to fix other people’s issues several months after their 
commits.
 >> It’s
>> > >> really handy and saves you hours when you can quickly link issue
 and
 >> code.
>> > >> Again remember that xwiki-contrib is NOT for solo projects. When
 you
 >>> put
 >>> > >> your project there you want it to be developed collaboratively
 and
  >>
join a
>> > >> community.
>> > >>>
>> > >>> 7) Edy said: "when all he wants to do is to fix a typo in
 XWiki's UI
 >> or
>> > >> align some labels, all through a simple GitHub fork & pull
 request.”.
 >> This
>> > >> is still possible right now. It’s more a question of best 
practice.
 >>> Would
 >>> > >> we want to apply a PR without a JIRA? For a label name change
 or a
  >>
typo I’d
>> > >> say definitely. BTW we don’t create jira issues for this either
 in the
 >> > >> “core”… (at least it’s not
mandatory, see dev.xwiki.org).
>> > >>>
>> > >>> In conclusion:
>> > >>> - I’m also tempted by the GH issues approach because it’s close
 to
 >> the
>> > >> code. If we were to decide to let contrib projects use GH issues
 then
 >>> I
 >>> > >> would also like to switch the “core” to GH issues. I see the
 whole
  >>> xwiki
 >>> > >> contributing/committers as a single community using the same
 >>> > >> tools/practices as much as possible.
 >>> > >>> - However, so far I see more drawbacks than pros: global
 search,
  >>
global
>> > >> view of all issues, advanced features of jira when they are 
needed,
 >> graphs,
>> > >> stats, single tool to support
>> > >>> - I’d be for improving our configuration of JIRA (less fields
 visible
 >>> > >> when creating issues, work on creating a template for more
 easily
  >>
creating
>> > >> jira projects)
>> > >>> - I’d like to keep a high level of quality of the XWiki 
ecosystem,
 >> not
>> > >> just at code level but at also tool level. When people go to our
 jira
 >>> they
 >>> > >> see it’s well organized and well maintained (no missing 
versions,
  >>
issues
>> > >> are closed when they should be, issues are sorted, they have 
labels
 >>> > >> applied, etc). This is part of what the XWiki project shows to
 the
  >>> outside
 >>> > >> and I’m proud of it and I think when contributors join the
 project
  >>> it’s
 >>> > >> also because they want to learn all this and they’re
interested  in
  >>> joining
 >>> > >> a select community with strong software development rules.
 >>> > >>>
 >>> > >>> Thanks
 >>> > >>> -Vincent
 >>> > >>>
 >>> > >>> On 24 Sep 2014 at 16:43:58, Sergiu Dumitriu
(sergiu(a)xwiki.com
 >>> (mailto:
 >>> > >> sergiu(a)xwiki.com)) wrote:
 >>> > >>>
 >>> > >>>> The same day that you send this vote, this article is
 published:
  >>
> >>>>
>> > >>
>> 

http://opensource.com/business/14/9/community-best-practices-new-era-open-s…
  >>> > >>>>
 >>> > >>>> Relevant quote:
 >>> > >>>>
 >>> > >>>> "[...] the contributor had to learn the specific
mechanisms  for
  >>
> >>>> contributing to their chosen project. Thus, if a contributor 
worked
 >>> > >>>> across several projects, they needed to learn several
 different
  >>
ways of
>> > >>>> doing things.
>> > >>>>
>> > >>>> Now there’s GitHub, and six million people use it. If your
 project
 >> is on
>> > >>>> GitHub, it means that no one has to learn special magic
tricks  to
 >> > >>>> contribute to your
project, because every project on GitHub  works in
 >>> > >>>> basically the same way. In the time it used to take a
user  just
  to
 >> > >>>> figure out a
project’s contribution mechanisms, a user can now  fork
 >> a
>> > >>>> repo, make a fix, and submit a pull request. The default
 instinct
 >> of new
>> > >>>> developers is no longer “suggest a change”—the instinct is
now  “fix
 >> the
>> > >>>> problem”.
>> > >>>>
>> > >>>>
>> > >>>> I've been using GitHub issues for almost 3 years now,
and I'm  pretty
 >> > >>>> happy with those.
Sometimes I miss the extra features of Jira,  but I
 >>> > >>>> also like the simplicity of this simple issues
tracker.
 >>> Supplementing
 >>> > >>>> Jean's answer, creating a Jira issue is a lot of
work, having  to
  >>
decide
>> > >>>> what version is affected, the relevant components, labels,
>> environment,
>> > >>>> priority... A GitHub issue can be just a title, and it
takes
>> seconds to
>> > >>>> create.
>> > >>>>
>> > >>>> Most of the arguments in favor of Jira are about aiding the
 XWiki
 >> > >>>> overlords: how do
we measure ALL the activity across all  projects?
 >> How
>> > >>>> is that relevant for a simple contributor that just wants
to
>> scratch an
>> > >>>> itch? We should make it as easy as possible to contribute.
>> > >>>>
>> > >>>>
>> > >>>> Another argument for GH Issues is locality: there's
only one  place
 >> for
>> > >>>> code, issues, roadmap, and discussions. With GH Wiki,
 documentation
 >> as
>> > >> well.
>> > >>>>
>> > >>>>
>> > >>>> So, I think there are good reasons why someone would prefer
 having
 >> > >>>> everything on
GitHub, we shouldn't enforce what we thing is  best on
 >> > >>>> someone else's
project.
>> > >>>>
>> > >>>> On 09/23/2014 09:22 AM, vincent(a)massol.net wrote:
>> > >>>>> Hi everyone,
>> > >>>>>
>> > >>>>> ATM the rule we have for contrib projects is to use
JIRA (see
>> > >> 
http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HHostingtools)
 >>> > >>>>>
 >>> > >>>>> I’ve heard that some people have been proposing
using other
 >>> trackers.
 >>> > >>>>>
 >>> > >>>>> So I’d like to poll your opinion on the following
 alternatives:
  >>
> >>>>>
>> > >>>>> Option A: all projects use JIRA
>> > >>>>> ===============================
>> > >>>>>
>> > >>>>> This is the current option in use.
>> > >>>>>
>> > >>>>> Pros:
>> > >>>>> * A single place for people to view and search for
issues in  the
 >>> XWiki
 >>> > >> Ecosystem
 >>> > >>>>>
 >>> > >>>>> Cons:
 >>> > >>>>> * For XWiki admins, creating a new JIRA project
takes 5  minutes
  >>
> >>>>>
>> > >>>>> Option B: all projects use GitHub issues
>> > >>>>> ========================================
>> > >>>>>
>> > >>>>> Pros:
>> > >>>>> * Simple to set up for admins (hosted by GitHub)
>> > >>>>> * Simple to use (too simple sometimes?)
>> > >>>>>
>> > >>>>> Cons:
>> > >>>>> * No single place to search all issues related to XWiki
(both  JIRA
 >>> +
 >>> > >> GitHub)
 >>> > >>>>> * No single place to report JIRA issues
 >>> > >>>>> * Tied to the SCM choice. When we stop using Git
as our SCM  and
  >>
move
>> > >> to the next SCM tool we’ll have to import all issues (see
>> > >>
>> 

https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-i…
  >>
> >> )
>> > >>>>> * Need to implement feature on extensions.xwiki.org to
add a  link
 >> to
>> > >> the issue tracker for each extension
>> > >>>>>
>> > >>>>> Option C: let each project decide
>> > >>>>> =================================
>> > >>>>>
>> > >>>>> Pros:
>> > >>>>> * Simple to set up for admins when project decides on
GitHub
>> > >>>>>
>> > >>>>> Cons:
>> > >>>>> * No single place to search all issues related to XWiki
(both  JIRA
 >>> +
 >>> > >> GitHub)
 >>> > >>>>> * No single place to report JIRA issues
 >>> > >>>>> * Tied to the SCM choice. When we stop using Git
as our SCM  and
  >>
move
>> > >> to the next SCM tool we’ll have to import all issues (see
>> > >>
>> 

https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-i…
  >>
> >> )
>> > >>>>> * Need to implement feature on extensions.xwiki.org to
add a  link
 >> to
>> > >> the issue tracker for each extension
>> > >>>>>
>> > >>>>> Option D: XWiki Task Manager
>> > >>>>> ============================
>> > >>>>>
>> > >>>>>
>> > >>
>> 

http://extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Applicati…
  >>
> >>>>>
>> > >>>>> Pros:
>> > >>>>> * Eat our own dog food.
>> > >>>>> * Forces us to improve this extension
>> > >>>>>
>> > >>>>> Cons:
>> > >>>>> * Pressure to fix bugs
>> > >>>>> * Increases volume of data on xwiki.org and thus
impact
>> performances
>> > >>>>> * Maintenance cost: More work when upgrading xwiki.org
>> > >>>>> * No single place to search all issues related to XWiki
(both  JIRA
 >> +
>> > >> GitHub)
>> > >>>>> * No single place to report JIRA issues
>> > >>>>> * Need to implement feature on extensions.xwiki.org to
add a  link
 >> to
>> > >> the issue tracker for each extension
>> > >>>>>
>> > >>>>> WDYT? Other options?
>> > >>>>>
>> > >>>>> Personally and based on all pros/cons I think the best
ATM is
>> really
>> > >> Option A. And if we really want, it’s possible to improve the
 cons by
 >> doing
>> > >> a bit of java coding:
>> > >>
>> 

https://developer.atlassian.com/display/JIRADEV/Creating+a+Project+Template
   > > >>>>>
> > >>>>> Thanks
> > >>>>> -Vincent
> > >>>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Sergiu Dumitriu
> > >>>> http://purl.org/net/sergiu
> > >>>> _______________________________________________
> > >>>> 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
> > >>>
> > >>
> > >> _______________________________________________
> > >> 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
> > >
> >
> >
> > --
> > Caleb James DeLisle
> > XWiki SAS
> > calebjamesdelisle(a)xwiki.com
> > _______________________________________________
> > 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
>
 _______________________________________________
 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 

 --
 Thomas Mortagne
 _______________________________________________
 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Re: [xwiki-devs] [Brainstorming] Issue tracking for xwiki-contrib projects