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 ([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
