On Tue, Sep 23, 2014 at 3:38 PM, vincent(a)massol.net <vincent(a)massol.net> wrote: I was of course talking only about xwiki-contrib when I said "github" but again in the mail people ask for a project on github and we don't automatically create jira project for them unless they also ask for it. -- Thomas Mortagne

  On 23 Sep 2014 at 16:07:09, Jean SIMARD (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote: 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 23 Sep 2014 at 16:43:23, Jean SIMARD (jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) wrote: 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 Sure it’s not. That’s why it was an option to improve it. 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

On Tue, Sep 23, 2014 at 05:07:30PM +0200, vincent(a)massol.net wrote: I disagree, creating a pull request create an history about the bug. That's what bug tracking is for, keep history about something. So either you create a bug issue OR a pull request. Of course, this way, you'll not have an ID when doing commits for a pull request (but is it really useful?). I wonder how many people who are new in the community find a bug and report it on Jira without asking first on IRC or mailing list (or through comment in e.x.o)? In other words, is Jira really the entry point for reporting bugs for people or did they get where to report from the community? And since source code is also one of the main entry point for developers, we could ask to document where to report in the README.md. Indeed, they will need to search into issues or pull requests. But Github is well referenced by Google, isn't it? :-) Not sure of what you're talking here (maybe I'm not well informed about what happened in xwiki-commons/rendering/platform/xe). I'll be happy to participate and contribute if option D is chosen :-) OK. We alreaedy support Jira hosting so we could imagine supporting Task Manager hosting but I agree this will be more work. Anyway, this point could be discussed later, if Task Manager becomes a true competitor for the simple needs of xwiki-contrib. -- Jean Simard jean.simard(a)xwiki.com Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org

On 09/26/2014 06:10 PM, Eduard Moraru wrote: 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. -- Sergiu Dumitriu http://purl.org/net/sergiu

On 09/27/2014 03:36 PM, Eduard Moraru wrote: 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. -- Sergiu Dumitriu http://purl.org/net/sergiu/

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 both. If it’s hard for contributors it’s also hard for core developers and we might as well fix the issue for everyone. Last point is maintenance: lots of people (including some committers) don’t see the maintenance involved (cleaning up issues, maintaining the infrastructure - monitoring, restarts, upgrades of tools, ensuring the quality of the extensions, fixing documentation mistakes/missing items on e.x.o, etc). In practice there are very few committers who do this maintenance and we shouldn’t overburden them either. Offering too many choices means more burden on infrastructure/maintenance. This is why BTW that forges are usually reticent to offer more than one tool to use for each domain. 2) Seems we have 2 categories of people on this thread: A- those who consider that a single place for issues with the ability to have a global dashboard/search feature is key B- those who consider that it’s more important to offer freedom of issue tracker choice to contributors than the single place to search/view all issues Personally I’m more more in the category A because: - it means less maintenance - I believe global search and a global place for issues is important - I believe JIRA can be configured to be as simple as GH if that’s what we want (more below) 3) I agree that we should try to make our issue creation experience as simple as possible (some ideas below) 4) Note: If we were to allow using GH issues, we would also need to develop a {{ghissue}} macro for release notes on e.x.o similar to the {{jira}} macro. Not a big deal but would need to be done. 5) Sergiu mentioned: “ Supplementing Jean's answer, creating a Jira issue is a lot of work, having to decide what version is affected, the relevant components, labels, environment, priority... A GitHub issue can be just a title, and it takes seconds to create.”. I think this has more to do with how we setup our JIRA: - "having to decide what version is affected”. This is always needed for bugs, be it on JIRA or on GH issues. Also note that on JIRA the “affects version” field is NOT mandatory. We have a best practice of always filling it ourselves but we could change that rule and decide that we should fill it only for bugs for example. - "the relevant components”. Again this is optional in JIRA too. Actually now that JIRA makes it easy in the UI to edit fields (without having to go in edit mode) we could make all optional field not be visible in the Basic Issue Creation Field Scheme (what you see when you click on “Create Issue”). The only possible downside is that we will receive more mails. - “labels, environment”. Again this is optional too in JIRA. BTW in your link (https://github.com/phenotips/phenotips/issues/1116) you seem to also use that on GH issues so I don’t see the difference. - “priority” is also optional. - "A GitHub issue can be just a title, and it takes seconds to create”. And it’s exactly the same for a JIRA issue. All you need to fill in is the “summary" field :) In conclusion: this is not a differentiator between JIRA and GH issues. If we think it’s scary for a user to see the optional fields in the Basic Issue Creation Field Scheme, then let’s remove them from that screen now. 6) Regarding traceability by putting issue reference in commits it’s for us to decide whether we want this as a best practice or not. It does’t depend on the issue tracker we use. For example https://github.com/phenotips/phenotips/issues/1116 shows that it also exists in GH issues. Personally I think that it’s part of the best practices we should keep in the XWiki ecosystem but it could be discussed. Jean feels it a burden apparently. However I don’t know how often Jean has had to fix other people’s issues several months after their commits. It’s really handy and saves you hours when you can quickly link issue and code. Again remember that xwiki-contrib is NOT for solo projects. When you put your project there you want it to be developed collaboratively and join a community. 7) Edy said: "when all he wants to do is to fix a typo in XWiki's UI or align some labels, all through a simple GitHub fork & pull request.”. This is still possible right now. It’s more a question of best practice. Would we want to apply a PR without a JIRA? For a label name change or a typo I’d say definitely. BTW we don’t create jira issues for this either in the “core”… (at least it’s not mandatory, see dev.xwiki.org). In conclusion: - I’m also tempted by the GH issues approach because it’s close to the code. If we were to decide to let contrib projects use GH issues then I would also like to switch the “core” to GH issues. I see the whole xwiki contributing/committers as a single community using the same tools/practices as much as possible. - However, so far I see more drawbacks than pros: global search, global view of all issues, advanced features of jira when they are needed, graphs, stats, single tool to support - I’d be for improving our configuration of JIRA (less fields visible when creating issues, work on creating a template for more easily creating jira projects) - I’d like to keep a high level of quality of the XWiki ecosystem, not just at code level but at also tool level. When people go to our jira they see it’s well organized and well maintained (no missing versions, issues are closed when they should be, issues are sorted, they have labels applied, etc). This is part of what the XWiki project shows to the outside and I’m proud of it and I think when contributors join the project it’s also because they want to learn all this and they’re interested in joining a select community with strong software development rules. Thanks -Vincent On 24 Sep 2014 at 16:43:58, Sergiu Dumitriu (sergiu@xwiki.com(mailto:sergiu@xwiki.com)) 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 <cjd(a)cjdns.fr>fr>:

On 29 Sep 2014 at 11:24:19, Caleb James DeLisle (cjd@cjdns.fr(mailto:cjd@cjdns.fr)) wrote: 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 Wed, Oct 1, 2014 at 10:00 AM, Eduard Moraru <enygma2002(a)gmail.com> wrote: That would be awesome! Thanks, Marius

On Wed, Oct 1, 2014 at 11:22 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: 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