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

1 Oct 2014

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).

...
   - 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 &lt;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

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