On 23 Sep 2014 at 15:33:16, Thomas Mortagne ([email protected](mailto:[email protected])) wrote:

On Tue, Sep 23, 2014 at 3:22 PM, [email protected] 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)

It never been a rule for me but just something we provide, the only rule is that projects have to ask for it and you there is projects on github that don't have any jira project.

xwiki-contrib is provided by us and thus we decide the rules we want to use for it. This thread is about the solution we want to propose on the infrastructure managed by the XWiki committers. We don’t force anyone to join xwiki-contrib. They can use their own SCM and their own trackers but if they join xwiki-contrib they have some rules to follow (because we do the maintenance, because we want it done in a certain way, etc). Thanks -Vincent

...

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-im...) * 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-im...) * 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+Applicatio...

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

Oups sorry, indeed, it's not a vote. I think we don't need the heavy solution of JIRA (at least, as a mandatory tool for bug tracking) for xwiki-contrib. Each time I want to do a pull request on xwiki-contrib, I need to begin to create a Jira, to obtain a Jira ID (IDEA-2314 for example) then I will be able to use it in my commit message. I often began to work on the code long before creating a Jira which, as you can see, is not very easy in the workflow (being blocked at the commit level because of the need of an ID?). And then, I create my pull request on Github and then come back to Jira to give the link of this pull request. Maybe this heaviness is needed in xwiki repository (even not sure of that) but for applications/contributions, it's a probably too much in my opinion. For having work on Task Manager Application, I think option D is not enough mature even if it's an interesting solution (by the way, if option C is chosen, Task Manager will become a possibility). Hope this helps. On Tue, Sep 23, 2014 at 04:29:28PM +0200, [email protected] wrote:

 

On 23 Sep 2014 at 16:07:09, Jean SIMARD ([email protected](mailto:[email protected])) wrote:

...

+1 for C.

Jean could you please motivate your answer… This is not a vote but a brainstorming! :)

For example explain why the cons listed are not cons for you (or not important), or why the pros are more important than the cons.

Thanks -Vincent

...

On Tue, Sep 23, 2014 at 03:22:14PM +0200, [email protected] 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-im...) * 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-im...) * 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+Applicatio...

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

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org

Hi,

IMHO, ability to search for all (xwiki+contribs) issues from one location
is an awesome PRO. I would weight it as +10, not just +1 ! :)

Apart from the tool there are some process-related questions:
- do you want, mandatorily, traceability between issues and sources, for
xwiki AND contribs ?
- isn't it mandatory or at least heavily recommended, that people search
for possibly existing issue before logging a new one ? (or even, post
something to the mailing-lists)

If yes to those questions, it would bring:
- are you / will you be able to implement traceability sources/issues with
option D ? Easier to use than with Jira or Github ?
- spreading issues over multiple tools, would give a fair excuse to
everyone to NOT search for existing issues before logging new ones (and,
including myself, we don't need excuses, as I think many people forget
about this :D )

Jeremie


2014-09-23 17:07 GMT+02:00 [email protected] <[email protected]>:

>
>
>
>
>
> On 23 Sep 2014 at 16:43:23, Jean SIMARD ([email protected](mailto:
> [email protected])) wrote:
>
> > Oups sorry, indeed, it's not a vote.
> >
> > I think we don't need the heavy solution of JIRA (at least, as a
> mandatory tool
> > for bug tracking) for xwiki-contrib. Each time I want to do a pull
> request on
> > xwiki-contrib, I need to begin to create a Jira, to obtain a Jira ID
> (IDEA-2314
> > for example) then I will be able to use it in my commit message. I often
> began
> > to work on the code long before creating a Jira which, as you can see,
> is not
> > very easy in the workflow (being blocked at the commit level because of
> the need
> > of an ID?). And then, I create my pull request on Github and then come
> back to
> > Jira to give the link of this pull request. Maybe this heaviness is
> needed in
> > xwiki repository (even not sure of that) but for
> applications/contributions,
> > it's a probably too much in my opinion.
>
> Some comments:
>
> * How is this different with GitHub issues? You still need to create the
> issue to get the id for your commits, no?
> * So you feel that when people go to http://jira.xwiki.org and try to log
> a new issue and they won’t find the project it won’t be an issue?
> * Same question for when they search for an existing issue.
> * It doesn’t seem to be an issue when we code in
> xwiki-commons/rendering/platform/xe
>
> > For having work on Task Manager Application, I think option D is not
> enough
> > mature even if it's an interesting solution
>
> Sure it’s not. That’s why it was an option to improve it.
>
> > (by the way, if option C is chosen,
> > Task Manager will become a possibility).
>
> Actually option C is badly named, my bad. It’s “Let the project decide
> among a list of tools the xwiki.org committers support”.
>
> And supporting the Task Manager is not a given (see my list of cons below)
> ;)
>
> Thanks
> -Vincent
>
> > Hope this helps.
> >
> > On Tue, Sep 23, 2014 at 04:29:28PM +0200, [email protected] wrote:
> > >
> > >
> > >
> > >
> > >
> > > On 23 Sep 2014 at 16:07:09, Jean SIMARD ([email protected](mailto:
> [email protected])) wrote:
> > >
> > > > +1 for C.
> > >
> > > Jean could you please motivate your answer… This is not a vote but a
> brainstorming! :)
> > >
> > > For example explain why the cons listed are not cons for you (or not
> important), or why the pros are more important than the cons.
> > >
> > > Thanks
> > > -Vincent
> > >
> > > > On Tue, Sep 23, 2014 at 03:22:14PM +0200, [email protected] 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-importers-github-plugin/versions
> )
> > > > > * 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-importers-github-plugin/versions
> )
> > > > > * 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+Application
> > > > >
> > > > > 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
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>

...talk about "Contributions pain points". I have to say, I agree with Sergiu here. We might be a bit swimming against the tide here, since, from a regular-Joe contributor's point of view we`re coming with all these restrictions and accounts, infrastructure and procedures, 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. I agree that Jira (or at least our current procedure for fist creating an issue and the committing on that issue) comes with all this nice tractability (and that sweet "Commits" tab that yes, it is very useful), but maybe we should consider the option of enforcing this only for committers (which are seasoned developers that know how to follow simple and clean procedures and that are working on more complex tasks), but when it comes to regular contributors, to loosen up this requirement and just be happy we get their pull requests. Regarding the actual topic of this thread, perhaps option C would be best, in the idea that we clearly recommend they should use Jira for the various listed reasons, but otherwise the e.x.o page of their application should be the nr.1 location that links to the code, to the issue tracker and to the downloads. We are talking about contributions here, after all, and AFAIK the reality is that most contributions are not rocket science hugely multi-module projects that need complex issue tracking and componentization, so people might be highly tempted to go for a lighter approach that is more integrated into their everyday workflow. My 2 cents, Eduard P.S.: I`m fairly sure that writing a quick greasemonkey userscript for GitHub to simulate a Jira-like "Commits" tab would be quick and easy to do, since issues are already supported to be referenced from commit messages. What is missing right now is the other way around, for issues to list all commits referencing them. On Wed, Sep 24, 2014 at 5:43 PM, Sergiu Dumitriu <[email protected]> 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-so...

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, [email protected] 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-im... ) * 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-im... ) * 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+Applicatio...

...

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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Sat, Sep 27, 2014 at 3:32 PM, Sergiu Dumitriu <[email protected]> wrote:

On 09/26/2014 06:10 PM, Eduard Moraru wrote:

...

P.S.: I`m fairly sure that writing a quick greasemonkey userscript for GitHub to simulate a Jira-like "Commits" tab would be quick and easy to do, since issues are already supported to be referenced from commit messages. What is missing right now is the other way around, for issues to list all commits referencing them.

That already happens, see https://github.com/phenotips/phenotips/issues/1116 for example. Just that commits are mixed with other activity. This is like Jira's Activity tab, with all events listed. The requirement is that commits mention #NNN, so this still requires an issue number. Pull requests numbers are assigned when the PR is made, so after the commits happened, so in this case the user has to either guess the PR number (and hope that nobody else makes a PR first), or amend all the commits to insert the issue number.

Ah, cool then! I looked at a few github projects for that kind of stuff but did not find it. I did see issues being referenced in commit messages, but on the issue's page I did not see anything about those commits. Maybe it's something you need to explicitly enable for your repo, anyway. I don`t really see the connection with Pull Requests here, since the *issue* can be created (if it does not already exist), the commits can be made with that issue mentioned and then they can be published through a pull request. Perhaps you were describing a different flow, where someone commits, makes a pull request and only after they think about creating an issue to track it, so they have to amend the commits... Thanks, Eduard

-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Sat, Sep 27, 2014 at 11:16 PM, Sergiu Dumitriu <[email protected]> wrote:

On 09/27/2014 03:36 PM, Eduard Moraru wrote:

...

On Sat, Sep 27, 2014 at 3:32 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 09/26/2014 06:10 PM, Eduard Moraru wrote:

...

P.S.: I`m fairly sure that writing a quick greasemonkey userscript for GitHub to simulate a Jira-like "Commits" tab would be quick and easy to do, since issues are already supported to be referenced from commit messages. What is missing right now is the other way around, for issues to list all commits referencing them.

That already happens, see https://github.com/phenotips/phenotips/issues/1116 for example. Just that commits are mixed with other activity. This is like Jira's Activity tab, with all events listed. The requirement is that commits mention #NNN, so this still requires an issue number. Pull requests numbers are assigned when the PR is made, so after the commits happened, so in this case the user has to either guess the PR number (and hope that nobody else makes a PR first), or amend all the commits to insert the issue number.

Ah, cool then! I looked at a few github projects for that kind of stuff but did not find it. I did see issues being referenced in commit messages, but on the issue's page I did not see anything about those commits. Maybe it's something you need to explicitly enable for your repo, anyway.

I don`t really see the connection with Pull Requests here, since the *issue* can be created (if it does not already exist), the commits can be made with that issue mentioned and then they can be published through a pull request. Perhaps you were describing a different flow, where someone commits, makes a pull request and only after they think about creating an issue to track it, so they have to amend the commits...

Pull requests and issues are almost the same thing on GitHub. Well, at least one way, pull requests can be issues, but not the other way around:

- a pull request has a number (and the same sequence is used both for issues and PRs) - pull requests can have labels, assignee, target milestone - they appear in the milestone's list of open/closed issues - they are included in the issue search if you remove the "is:issue" search filter

So yes, another workflow possible on GitHub is to just make a pull request and treat it as an issue. Otherwise, there are two places where the discussion happens: in the pull request, and in the issue. And you have to make sure only one of them is assigned to a milestone, otherwise users will see both.

Ah, right... I did notice something like that. I guess the following workflow does not make sense when using GitHub: 1. Detect and fix a problem 2. Create an issue to track it 3. Create a pull request and push your changes (mentioning the issue) 4. Profit I`m assuming GitHub is intended to jump directly from step 1 to step 3 (which is the issue) in an effort to get to step 4 as soon as possible, stressing the "agile" part of a project's development. So one way of seeing this is that issues are for the project's committers and pull requests are for the project's contributors. Both are used to track changes... and, while committers can be a bit more disciplined to first create an issue and then reference it in the commit message, contributors are not expected to do that and the pull request created is considered enough. Thanks for the clarifications, Eduard

-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

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, [email protected] 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 ([email protected](mailto:[email protected])) 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-so...

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, [email protected] 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-im...) * 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-im...) * 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+Applicatio...

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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

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. 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 <[email protected]>:

...

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, [email protected] 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 ([email protected](mailto: [email protected])) 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-so...

...

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, [email protected] 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-im... ) * 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-im... ) * 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+Applicatio...

...

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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Caleb James DeLisle XWiki SAS [email protected]

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)
- 1 nexus account
... when he already has a "developer" account on GitHub.

WDYT?

Thanks,
Eduard

On Mon, Sep 29, 2014 at 12:49 PM, [email protected] <[email protected]>
wrote:

>
>
>
> On 29 Sep 2014 at 11:24:19, Caleb James DeLisle ([email protected](mailto:
> [email protected])) 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, [email protected] 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 ([email protected]
> (mailto:
> > >> [email protected])) 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-source
> > >>>>
> > >>>> 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, [email protected] 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-importers-github-plugin/versions
> > >> )
> > >>>>> * 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-importers-github-plugin/versions
> > >> )
> > >>>>> * 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+Application
> > >>>>>
> > >>>>> 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
> > >>>> [email protected]
> > >>>> http://lists.xwiki.org/mailman/listinfo/devs
> > >>> _______________________________________________
> > >>> devs mailing list
> > >>> [email protected]
> > >>> http://lists.xwiki.org/mailman/listinfo/devs
> > >>>
> > >>
> > >> _______________________________________________
> > >> devs mailing list
> > >> [email protected]
> > >> http://lists.xwiki.org/mailman/listinfo/devs
> > >>
> > > _______________________________________________
> > > devs mailing list
> > > [email protected]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> >
> >
> > --
> > Caleb James DeLisle
> > XWiki SAS
> > [email protected]
> > _______________________________________________
> > devs mailing list
> > [email protected]
> > http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>

On Wed, Oct 1, 2014 at 10:15 AM, Marius Dumitru Florea
<[email protected]> wrote:
> On Wed, Oct 1, 2014 at 10:00 AM, Eduard Moraru <[email protected]> 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+Application
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, [email protected] <[email protected]>
>> wrote:
>>
>>>
>>>
>>>
>>> On 29 Sep 2014 at 11:24:19, Caleb James DeLisle ([email protected](mailto:
>>> [email protected])) 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, [email protected] 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 ([email protected]
>>> (mailto:
>>> > >> [email protected])) 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-source
>>> > >>>>
>>> > >>>> 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, [email protected] 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-importers-github-plugin/versions
>>> > >> )
>>> > >>>>> * 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-importers-github-plugin/versions
>>> > >> )
>>> > >>>>> * 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+Application
>>> > >>>>>
>>> > >>>>> 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
>>> > >>>> [email protected]
>>> > >>>> http://lists.xwiki.org/mailman/listinfo/devs
>>> > >>> _______________________________________________
>>> > >>> devs mailing list
>>> > >>> [email protected]
>>> > >>> http://lists.xwiki.org/mailman/listinfo/devs
>>> > >>>
>>> > >>
>>> > >> _______________________________________________
>>> > >> devs mailing list
>>> > >> [email protected]
>>> > >> http://lists.xwiki.org/mailman/listinfo/devs
>>> > >>
>>> > > _______________________________________________
>>> > > devs mailing list
>>> > > [email protected]
>>> > > http://lists.xwiki.org/mailman/listinfo/devs
>>> > >
>>> >
>>> >
>>> > --
>>> > Caleb James DeLisle
>>> > XWiki SAS
>>> > [email protected]
>>> > _______________________________________________
>>> > devs mailing list
>>> > [email protected]
>>> > http://lists.xwiki.org/mailman/listinfo/devs
>>> _______________________________________________
>>> devs mailing list
>>> [email protected]
>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>
>> _______________________________________________
>> devs mailing list
>> [email protected]
>> http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs



-- 
Thomas Mortagne

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

On Wed, Oct 1, 2014 at 7:42 AM, Eduard Moraru <[email protected]> wrote:

> On Wed, Oct 1, 2014 at 11:22 AM, Thomas Mortagne <
> [email protected]>
> wrote:
>
> > On Wed, Oct 1, 2014 at 10:15 AM, Marius Dumitru Florea
> > <[email protected]> wrote:
> > > On Wed, Oct 1, 2014 at 10:00 AM, Eduard Moraru <[email protected]>
> > 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+Application
> > 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, [email protected] <
> > [email protected]>
> > >> wrote:
> > >>
> > >>>
> > >>>
> > >>>
> > >>> On 29 Sep 2014 at 11:24:19, Caleb James DeLisle ([email protected]
> (mailto:
> > >>> [email protected])) 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, [email protected] 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 ([email protected]
> > >>> (mailto:
> > >>> > >> [email protected])) 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-source
> > >>> > >>>>
> > >>> > >>>> 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, [email protected] 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-importers-github-plugin/versions
> > >>> > >> )
> > >>> > >>>>> * 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-importers-github-plugin/versions
> > >>> > >> )
> > >>> > >>>>> * 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+Application
> > >>> > >>>>>
> > >>> > >>>>> 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
> > >>> > >>>> [email protected]
> > >>> > >>>> http://lists.xwiki.org/mailman/listinfo/devs
> > >>> > >>> _______________________________________________
> > >>> > >>> devs mailing list
> > >>> > >>> [email protected]
> > >>> > >>> http://lists.xwiki.org/mailman/listinfo/devs
> > >>> > >>>
> > >>> > >>
> > >>> > >> _______________________________________________
> > >>> > >> devs mailing list
> > >>> > >> [email protected]
> > >>> > >> http://lists.xwiki.org/mailman/listinfo/devs
> > >>> > >>
> > >>> > > _______________________________________________
> > >>> > > devs mailing list
> > >>> > > [email protected]
> > >>> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >>> > >
> > >>> >
> > >>> >
> > >>> > --
> > >>> > Caleb James DeLisle
> > >>> > XWiki SAS
> > >>> > [email protected]
> > >>> > _______________________________________________
> > >>> > devs mailing list
> > >>> > [email protected]
> > >>> > http://lists.xwiki.org/mailman/listinfo/devs
> > >>> _______________________________________________
> > >>> devs mailing list
> > >>> [email protected]
> > >>> http://lists.xwiki.org/mailman/listinfo/devs
> > >>>
> > >> _______________________________________________
> > >> devs mailing list
> > >> [email protected]
> > >> http://lists.xwiki.org/mailman/listinfo/devs
> > > _______________________________________________
> > > devs mailing list
> > > [email protected]
> > > http://lists.xwiki.org/mailman/listinfo/devs
> >
> >
> >
> > --
> > Thomas Mortagne
> > _______________________________________________
> > devs mailing list
> > [email protected]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>