On Mon, Jun 25, 2012 at 8:18 AM, Sebastian Kügler <se...@kde.org> wrote: > On Friday, June 22, 2012 15:11:42 Myriam Schweingruber wrote: >> What needs to be understood is that all code can have bugs, that is >> only natural and nobody will deny that. But that also means that we >> should thrive to make the code better, and IMHO to some extend a >> developer should feel responsible for the code s/he commits and also >> take care of the bugs that are found. >> >> While I understand that nobody likes pressure it should also be >> understood the perception from the other side: developers not even >> looking at bugs in their own code are perceived as arrogant and >> uncooperative. With the current situation the politics of putting the >> head in the ground or just walking away with the "I don't have time" >> wave is not going to help, so efforts need to be done on all sides. > > You seem to be implying that putting pressure onto people is going to change > this: a fallacy. It actually works the other way round. If you put this kind > of pressure onto people, they'll turn around and go elsewhere, so you're > actually decreasing the resources available to fix bugs.
This "pressure" can be in the form of encouragement, organisation and good examples. This has to come from the top-down of the project, as everyone respects (and therefore copies) their elders. It's counterintuitive, so easy to make this mistake. Yet, it's still a mistake. > I agree with your goals, I disagree with "put pressure onto people" being a > valid way to deal with that -- it's detrimental to motivation and counter- > productive to our shared goal, which is improving the quality of our software. > > I've elaborated on ways to make developers care, but now I doubt that message > actually got through, so let me try to repeat it as concise as possible: > > - respect and being friendly are paramoumt to everything > - don't put blame or extra pressure onto the people who are already doing the > work > - don't try making decisions about priorities for others, instead provide > information that makes it easier to prioritize, but accept others priorities > - developers handle chopped up pieces better than drinking from the firehose > (your regression lists are awesome in that respect, also aids prioritizing) > - bug squashing, like most other activities in Free software needs to happen > bottom-up > - we collaborate instead of dictating and blaming > I trust you'll be at the BOF? Martin G is doing an amazing job with a very difficult product with regards to bugs and is clearly a bug-wizard. We've adopted several of Martin's suggestions in KTp along with some of our own ideas (which I'll be happy to share) and for us bugs aren't a chore, they're a useful part of the workflow. No point discussing this on the mailing list anymore - see you in 2 days :) > Cheers, > -- > sebas > > http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 > _______________________________________________ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel