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