On Wed, Oct 1, 2014 at 10:00 AM, Eduard Moraru <enygma2...@gmail.com> 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) > - 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, vinc...@massol.net <vinc...@massol.net> > wrote: > >> >> >> >> On 29 Sep 2014 at 11:24:19, Caleb James DeLisle (c...@cjdns.fr(mailto: >> c...@cjdns.fr)) 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, vinc...@massol.net 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 (ser...@xwiki.com >> (mailto: >> > >> ser...@xwiki.com)) 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, vinc...@massol.net 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 >> > >>>> devs@xwiki.org >> > >>>> http://lists.xwiki.org/mailman/listinfo/devs >> > >>> _______________________________________________ >> > >>> devs mailing list >> > >>> devs@xwiki.org >> > >>> http://lists.xwiki.org/mailman/listinfo/devs >> > >>> >> > >> >> > >> _______________________________________________ >> > >> devs mailing list >> > >> devs@xwiki.org >> > >> http://lists.xwiki.org/mailman/listinfo/devs >> > >> >> > > _______________________________________________ >> > > devs mailing list >> > > devs@xwiki.org >> > > http://lists.xwiki.org/mailman/listinfo/devs >> > > >> > >> > >> > -- >> > Caleb James DeLisle >> > XWiki SAS >> > calebjamesdeli...@xwiki.com >> > _______________________________________________ >> > devs mailing list >> > devs@xwiki.org >> > http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> devs@xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
