Re: [xwiki-devs] [Brainstorming] Issue tracking for xwiki-contrib projects

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, vincent(a)massol.net wrote: 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. have a global dashboard/search feature is key tracker choice to contributors than the single place to search/view all issues we want (more below) simple as possible (some ideas below) 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. 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.”. 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. 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. link (https://github.com/phenotips/phenotips/issues/1116) you seem to also use that on GH issues so I don’t see the difference. And it’s exactly the same for a JIRA issue. All you need to fill in is the “summary" field :) 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. 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. 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). 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. view of all issues, advanced features of jira when they are needed, graphs, stats, single tool to support when creating issues, work on creating a template for more easily creating jira projects) 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. sergiu(a)xwiki.com)) wrote: http://opensource.com/business/14/9/community-best-practices-new-era-open-s… well. http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HHostingtools) Ecosystem GitHub) to the next SCM tool we’ll have to import all issues (see https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-i… ) the issue tracker for each extension GitHub) to the next SCM tool we’ll have to import all issues (see https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-i… ) the issue tracker for each extension http://extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Applicati… GitHub) >>> * No single place to report JIRA issues the issue tracker for each extension 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 _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs