[Owncloud] Discussion about how we should organize the issue tracker.

[Thomas Müller]

Full ack +1


Am Donnerstag, dem 03.05.2012 um 19:59 schrieb Stefan Eriksson:
> Hi I feel we need to discuss how to organize all entries at http://bugs.owncloud.org/thebuggenie/, today we have an almost empty roadmap: http://bugs.owncloud.org/thebuggenie/owncloud/roadmap and a massive amount of uncategorized issues at the mainpage. It's very hard to follow and keep track of what to expect out of the next release. 
> 
> Today there are two separate changelogs, one here: http://gitorious.org/owncloud/pages/OwnCloud4Features (http://gitorious.org/owncloud/pages/OwnCloud3Features) and the other http://bugs.owncloud.org/thebuggenie/owncloud/roadmap.
> 
> I see no point in having both of these. We should choose one or the other.
>

The wiki pages can be dropped in this case.
 
> I vote for a scenario where http://bugs.owncloud.org/thebuggenie/ acts as a frontend for http://gitorious.org/owncloud. All issue tracking and reporting/scheduling is handled by http://bugs.owncloud.org/thebuggenie/
>

VCS-Integration would be nice:
Within a commit message the developer references a ticket and a git hook (to be installed on gitorious) will push the changeset to buggenie.
By coupling these two systems you can easily see the ticket belonging to the commit and vice versa see in the tracker all commits for a ticket.

This will help a lot for e.g. cherry picking or just analysis of a ticket. 

 
> http://bugs.owncloud.org/thebuggenie/owncloud/roadmap has a ""Targetted for" entry and if all bugs and feature requests etc are maintained by the included "Targetted for ownCloud * Release" it will be a great tool for scheduling which features/bugs will be expected to be added/fixed for the upcoming milestones/releases.
> 
> For this to function though I feel there has to be some moderation, a few people who can categorize these issues into milestones, first when a merge request is well on its way it would be categorized (there probably has to be a "in the future" milestone aswell) into one of the release milestones. 
> 

In order to enable the 'moderator team' to handle new requests properly I'd suggest to nominate one main responsible for each component, who knows the component be heart 
and can easily judge on a feature request if bug.
E.g. there are file path issues with the sync client: Klaas will know the answer right away. Whereas e.g. the dev working on the iPhone app hav no clue at all.

I volunteer for the being a member of the moderation team. Anybody else?

And I nominate myself being responsible for all Debian Packages on OBS (ownCloud, ownCloud client and it's dependencies).

> Also bugfixes should be categorized depending on how much work it would take to implement plus how critical it is to fix.
>

In addition we need the field for the version the issue was detected.

An I miss the component field on feature request/enhancements.
 
> I dont think its a good idea to have the person reporting a bug (as long as its not him/her fixing it themselves) to set the "Targetted for" tag as they probably dont know the answer to the above. (how much work it would take to implement plus how critical it is to fix.) this is why I feel there has to be some kind of moderation. 
> 
> I feel the default option for targeted release should be "in the future" and at this time a moderator would look at the issue and either keep it at the default milestone or move it to a more appropiate.
> 
> How does everyone think about organizing the issue tracker, to get a better overview of it all? this is just a mail to get the ball running please discuss :)
> 
> /Stefan


Just a final statement: once the buggenie is treated well - it will be far better than the github issues! ;-)

Tom aka DeepDiver