<div dir="ltr">Hi folks,<div><br></div><div style>there was a discussion on irc about the issue handling, milestones, bugs verification, ... ended up to summarize this in an email.</div><div style><br></div><div style>For example there are issues pointing at the 5.0.4 RC and probaly unfixed. They're insufficient critical to be a showstopper for 5.0.4 but should be kept in mind for i.e. 5.1. So it would be great to move them to a "5.1 milestone". Just some clicks but a cleanup of the issue list. This example was the starting point, because 5.0.4 is released but it seems to have some relevant issues.</div>

<div style><br></div><div style>Back to another example: There are some things which are wishes but will not be fixed in the next release but also should  kept in mind. For this type of issue (i.e. wonderful and great feature for owncloud 10) there should be a "future" or "dreamland" named milestone.</div>

<div style><br></div><div style>There was a mention about how to point a developer to a specific, very relevant issue. Currently he is often mailed directly. Isn't it better to assign the specific developer via github (left side directly under the issue title). It's the purpose of this bug tracker ;) So why not use it. Often less work for the project leader (just click assign and chose the developer) and less "searching in mails and figure out corresponding issue on github" for the developer, who just goes to <a href="http://github.com/owncloud/REPO/issues">github.com/owncloud/REPO/issues</a> and click "Assigned to you" in the upper right. The now listed bugs are verified, relevant and the whole communication isn't distributed (e-mail, github issues).</div>

<div><br></div><div>All issues should be verified before the assignment to a milestone.</div><div style><br></div><div style>Also it's more transparent to others (current developers also as beginners).</div><div style>

<br></div><div style>All this is a great starting point for a all contributors.</div><div style><br></div><div style>This should be an inspiration for a better issue management and a use of existing infratructure at github.</div>

<div style><br></div><div style>That are just some thoughts from kiranos and me and aren't the answer to everything. So critical answers, questions, improvement suggestions, etc. are welcome. (Maybe I've forgotten something, but this is just a quick and dirty writing down)</div>

<div style><br></div><div style>Best regards,</div><div style>Morris Jobke</div></div>