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