+1 to this.<br><br><b><i>Stefan Andersson <stefan@tribalmedia.se></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">   <style> .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } </style> > > We don't need percieved owners of code parts. Obviously, the mantis <br>> > bugs aren't solved because people are more interested in working with <br>> > features than fixing bugs. That's not going away because you assign <br>> > stuff. Rather, it means that those bugs are zombies - living dead issues.<br>><br>> I agree with you about the "don't want percieved owners" part.  <br>> Unfortunately, though, if we only ever implement features instead of <br>> fixing bugs, we're not going to have a very useful project.<br><br>I totally agree with that. I see it thus:<br><br>1) We DO fix bugs. We just don't close as many mantis as
 are opened.<br>2) Some bugs are fixed 'in-process', when devs are coding on something and running into the bug and fixing it on-the-fly - but then they never bother to look it up in mantis to see if there's an issue on it.<br>3) In my world, it's quite simple: The project isn't mature enough to be percieved as of usable for a wider audience, and hence there's not enough incentive in any core dev to make it stable. This will change as the project starts to be used in mission-critical applications.<br><br>Or, in other words; what we need is<br>1) A wider community of bug managers - see this as  A CALL TO ARMS; FOLKS - yes, we need YOU!!<br><br>The community of 'bug managers' would:<br>* Monitor mantis for new bugs<br>* Reproduce the bug and 'confirm' it, together with own notes<br>* Continously Prioritize and re-prioritize bugs<br>* Hunt down patchers to do patches for issues, and relating the patch to the bug<br>* Apply patches and mark them as 'confirmed fixing issue'
 in mantis<br>* Hunt down core devs to apply patch<br>* Update their code and make sure the patch 'took'<br>* Close patch and related bug issues<br>* Continously monitoring 'old' issues and re-confirming them, possibly adding more information and re-prioritizing.<br><br>This would mean that we would take about 2/3's of the job off the core devs == getting 200% more bugs fixed.<br><br>Now, this is something obout a 100 people on this mailing list can be a part of. So, I urge you all, let's get this ball rolling!<br><br>and<br><br>2) Commercial-grade development<br><br>> > Also, if anything, people should be assigned bugs in areas they don't <br>> > know anything about, so we start spreading the knowledge.<br>> ><br>> > If we could get a mantis statistic up front on the wiki page, that <br>> > might be a motivator, though. Ie, reported/closed and closed by developer.<br>><br>> I quite like this idea, though perhaps just a
 reported/opened/closed <br>> summary and not a developer breakdown.<br><br>Yeah, well, if we have a community process like the one I sketched out above, it would be wrong to break it down, but if we continue work with this as being individual efforts, I think they should have the kudos, just like the committers have on ohloh.<br><br>Best,<br>/Stefan<br><br>_______________________________________________<br>Opensim-dev mailing list<br>Opensim-dev@lists.berlios.de<br>https://lists.berlios.de/mailman/listinfo/opensim-dev<br></blockquote><br><p>



      <hr size=1> 
Rise to the challenge for Sport Relief with <a href="http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=51947/*http://uk.promotions.yahoo.com/forgood/">Yahoo! for Good</a>