User:Chani/WayOfThePlasma/Categories/Policy

Why must patches be peer-reviewed before they can be committed?

Conclusion

It is hard for new contributers to see all possible consequences of the changes they introduce. This has lead to long-term issues in earlier projects.

Original Text

Aaron Seigo

now, last week saw many unreviewed commits that actually resulted in rather unecessary issues in the code base; (...) people have a tendency to fall back to methods that got us kicker and kdesktop (namely: really useful programs that did a ton of a stuff but were at a point where they hit a brick wall as far as being able to take them further).

free-for-all does have a very negative impact on the code base. we tried that, and we moved to peer review because of what that resulted in.

Sources

panel-devel archive (2008-02)

Is it ok to make changes, even if they expose bugs in other parts of Plasma?

Conclusion

Absolutely. All known issues must be addressed. Visible bugs motivate people to fix the problem.

Original Text

Aaron Seigo

this is a good way to ensure that the issue is never addressed. by removing the obvious pain, you've swept the problem under the rug. it's not even a hard problem either, but this commit helps ensure the problem stays there.

please do not route around bugs like this in the future. =)

Sources

panel-devel archive (2008-02)

I want an option to turn this bug off

Conclusion

Issues should be resolved, not hidden.

Original Text

Aaron Seigo

those kinds of options are there *only* to take away the pain/annoyance/whatever of a feature (or mis-feature, depending on the case). instead, if one works on tooling that feature into something better .. one gets a better tool and doesn't add yet more to the configuration load.

and yes, high configuration load does have a very negative impact on the user experience.

worse, if we let you turn this off now .. where will we get feedback on what we do with it so that we can figure out when/how it is more acceptable? no, you'll just all turn it off and never look back at it again. i'd rather try and *fix* issues rather than cover them up, with the result being a mess of code paths and half finished features.

moreover, as a feature in development, i'm very against making the implementation yet more complicated than necessary until we have some of the other fundamentals in place.

Sources

b.k.o comment

fixing the API

Original Text

Aaron Seigo

That's one of my favourite ways of working, actually: start with code that uses the API that should work but doesn't, get things to the point where they are working. The game is to do it without hacks, without API uglification and with as few new lines of code as possible.

Sources

friday

Example of constructive problem solving

Conclusion

This thread started out with a repeatedly discussed issue: how to make kickoff's selection more visually appealing.

At the time the text of the entry received a solid rectangle behind the text on hover, which did not span the complete width of kickoff.

There were two positions:

• The selection should be full width to make it not "jump" when the user moved from one item to another
• The selection should only be as wide as the text to focus attention on the text, which is the meaningful content.

(There was more to the issue, but these points should suffice to illustrate the process.)

The discussion achieved consensus on the following points:

• Selection should contain the sub-menu arrow
• Selection should span the icon (but not clash with it color-wise)
• Selection should not draw attention to the empty space
• The item itself should change its look, not be "passively" colored
• It should be clear which item is selected without having to select another one and observe the effect
• It should be pretty

After the discussion had reached this point it had created some unpleasant feelings for people with stronger opinions and seemed to end like many before it without a real solution.

A request to kde-artists started the discussion up again with a few patches trying different concepts being submitted.

One submission introduced an outline instead of a solid rectangle. To give more weight to the text a gradient was introduced on the outline drawing attention to the left of the selection (the text and icon). This solution addressed all issues and did not receive much criticism.

Lessons learned:

• Patches (and mockups) speak louder than words
• Fixing the problem not the symptoms takes a lot of work
• Once a problem is solved for good it doesn't come up in discussion again.

Sources

making kickoff have full-width selection rects (on hover) thread

One proposed solution

Proposed solution already looking much like the finished product

Tone of discussions

Conclusion

There was a period of time where too many discussions resulted in hurt feelings. This should be aggressively avoided.

Original text

Aaron Seigo

[an emotional tone] takes its toll on those around us

...

i'm included in that; i feel ok again (thanks to both Will and Sebas for helping out in various ways, btw), but the last few months of dealing with such comments from various angles left me extremely raw emotionally and i feel it has done long-term damage to a few relationships between myself others in the project. that sucks.

so there are consequences. i'd really like the plasma project to avoid that, and i think we had been doing a *very* good job of that. as people who weren't here before entered that changed, and i don't think that's fair of those people to do have brought that into this project. it was also not great that i didn't step in and say these things right from the beginning.

i'm going to try a lot harder to protect the peace in this project, and i won't be allowing crap to sit on this list and fester until it erupts into a real set of problems. if anyone has a personal issue with that, please be sure to close the door on your way out.

Sources

panel-devel 2008-02