Hi, This is just an idea: In the context of finding easier ways for our users to report issue for our e.x.o applications, me and Vincent played a bit with JIRA's Issue Collectors functionality. You can read more and see some screenshots at http://jira.xwiki.org/browse/XINFRA-132 If we consider this to be interesting, this functionality would be available to applications hosted on xwiki-contrib that have a jira.xwiki.orgproject attached to them.
Thanks, Caty On Tue, Jan 21, 2014 at 3:12 PM, [email protected] <[email protected]>wrote: > Hi Caty, > > On 17 Jan 2014 at 11:21:49, Ecaterina Moraru (Valica) ([email protected] > (mailto:[email protected])) wrote: > > > Hi, > > > > This mail should be seen as feedback for improving our e.x.o ( > > extensions.xwiki.org) and our contributions process, while answering > some > > of my questions :) > > > > Right now I am playing and testing some XWiki extensions from e.x.o. > > The problem that I have is that I don't know where is the best place to > > report bugs and issues. > > > > 1. First of all I think we should add a 'Issue Tracker' field in the > > repository application, where the developer should state where the issues > > should be reported (what is the preferred way of reporting and even if > the > > developer is available for further iterations of the extension). > > +1 to that, see http://jira.xwiki.org/browse/XWIKI-9682 > > > 2. What issue tracker we should use and how? > > Right now there are several ways the users can give feedback for a > certain > > extension: > > > > A. Direct e-mails to the developers: > > I've received couple of times e-mails with questions about the extensions > > I've developed. This approach is not recommended since we are doing open > > development and other users might have the same question. Usually I > suggest > > to use the mailinglist ( > > http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists ) if there > are > > additional questions, but an issue tracker could also solve the problem. > > I ask them to use the mailing list for questions and to report issues in > JIRA (I always make sure to create the required JIRA project if it doesn’t > already exist but usually there’s always one for my extensions). > > > B. Community mailinglist: > > We receive many questions about the extensions on the mailinglists. The > > problem is that the answers are very hard to track and share among other > > users (you need to know that the question has been asked before and than > > that an answer has been provided). An issue tracker would improve the > > process. > > > > C. Comments on the extension page: > > There are several extensions that have comments on their extension page. > > While this approach is the most accessible, it is hard to know what is > the > > status of a comment and the responsible person for it (was it fixed > > already? in what version? is the comment still valid?). > > > > D. GitHub issue tracker: > > While some extensions contain just snippet code or local XARs, other > have a > > repository attached to it. I know some extensions that track their issues > > on github. The advantages of this approach is that you keep total control > > of your extension and also you don't need approvals from xwiki community > to > > have your repository created or help with the management of it (rights, > > etc.). You handle your own development while using e.x.o as a publishing > > platform. The above statements are in case you have a personal > repository. > > The alternative is to have a repository on xwiki-contrib ( > > https://github.com/xwiki-contrib ), but these repository could also have > > the github issue tracker activated. > > > > E. jira.xwiki.org project: > > On jira.xwiki.org there is a whole section of Contributed Projects ( > > http://jira.xwiki.org/secure/BrowseProjects.jspa#all ). There is also a > > generic XWiki Contrib project ( http://jira.xwiki.org/browse/XCONTRIB ) > " to > > be used by all projects till they achieve a first release or till they > > grow to a size significant enough to warrant a dedicated JIRA project" > > (quote taken from http://contrib.xwiki.org/ ) > > > > F. IRC: > > Even harder than mailinglist to reference. > > > > G. other? > > > > I've written all the ways in order to agree on the recommended way > (which I > > guess is E.) while I don't think there is a way to force the others from > > happening. > > Our current strategy is to have a JIRA project for all active contrib > projects. Thomas and I have created a lot of JIRA projects for projects we > knew were active. Missing project need to be created. > > I agree that one difficulty is that the contributor doesn’t have the right > to create his own jira project. What we could do is: > - whenever someone ask for a repo on contrib, create a jira project by > default for him/her > - if possible automate it (I’ve researched a bit JIRA and even though they > have a notion of template projects it seems quite hard to use and require > some java coding, maybe someone need to research it a bit more). > > From the outset I’d think that using the same issue tracker for all is > best but I agree that using the GitHub issue tracker is tempting for > contrib extensions. If we were to do this we would need to decide how to > handle existing jira projects for contrib projects. > > > 3. Related extensions vs. Branched extensions vs. Forked extensions > > My problem is like this: Lets say I want to test the Forum Application. > > Currently there are 3 versions of the Forum application (read more at > > http://design.xwiki.org/xwiki/bin/view/Proposal/ForumApplication ). > > - First of all it was hard to know that we have 3 versions for the 'same' > > functionality. A feature like "Related extensions" would have been great > to > > have on e.x.o. > > I do a lot of gardening on this but I’d like help since this is my job to > do. Everyone should help here. So what I do is add some info box ({{info}} > macro) when I see an extension that’s made obsolete by another newer > extension. At least I try to explain about the reasons to choose one over > another. Everyone who introduces a new extension should always add such a > box. > > > - Then it was difficult to find out where is the place to report issues > for > > each of these applications (see the whole point of this mail). Currently > > there are 2 JIRA projects created for Forum (XAFORUM and XBB) but there > is > > no place to report for SimpleForumApp. > > This should be fixed by http://jira.xwiki.org/browse/XWIKI-9682 > > > - It was hard to know what version still work and if there is still > active > > development on it (especially if you have just an attached XAR and not a > > repository). > > Same answer as above with the info box. > > > - It is hard to know if the apps are completely different or if they are > > just forks of the same base code. Do they share the same functionality, > do > > they want to be improved versions or are just completely different > things? > > These questions are important because they give you an answer if the > > entries should have separate JIRA projects or we could solve the problem > by > > creating just a COMPONENT in the same JIRA project. > > Same answer as above with the info box. > > > - Whose responsibility is it to create the issue tracker, to link to the > > related applications, etc? (the developer? the contrib managers? other > > members of the community?) > > I’d say the person who creates the project on behalf of the contributor > who asks for a repo on xwiki-contrib. > > > The same questions apply for Calendar Application ( > > http://design.xwiki.org/xwiki/bin/view/Proposal/CalendarApplication ). I > > have 3 variants with other related extensions. The only extension that > has > > a JIRA project associated with it is the older extension. > > So, as an user of the extension, where do I report issues? > > - Do I need to ask for the creation of a separate project? > > - Do I ask for the creation of a separate component in the existing > project? > > - Do I report in the generic xcontrib project? > > - Do I need the permission of the developer to have the project created? > > You need to talk to the creators of the various “versions" to understand > if: > - the newer “version" has been rewritten from scratch, in which case it > should be a completely separate project with a different JIRA project and > different repo and different exo page. This means users can still install > both “versions". > - the newer “version" is an improvement (even if a big one) and in this > case it should have it’s major version upgraded (from 1.x to 2.0 for > example). In this case it’s the same github repo, same JIRA project, same > exo page. And users don’t install the old version anymore, the EM will > suggest the new version. > > > - Should we enforce the creation of projects for the new extensions? > > I don’t know what you mean by “enforce” but at least we should make it > clear on contrib.xwiki.org that whoever creates the new project should > also create the JIRA project (if we decide to continue with JIRA projects. > If we go the github tracker way then the creator should enable the github > issue tracker). It would be nice if we had a one click button to create a > new jira project from a template, right now it takes 5 minutes to create a > new one with the risk of making some mistakes. > > > - How we decide if an extension is big enough or important enough to have > > its own project? > > We changed our informal rule not long ago on this and decided to create > jira projects all the time even for new extensions. The doc on > contrib.xwiki.org needs to be updated. > > > - Who should monitor these growth? (since we actually don't know if the > > extensions are used or downloaded?) > > I’d everyone from the xwiki dev team should pay attention and help fix > problems. > > Thanks > -Vincent > > > Let me know what you think. > > Thanks, > > Caty > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
