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