On 06/20/2012 09:19 PM, Marco Martin wrote:
Hi all,
this is a very raw synopsis of the meeting, i hope we can now transform it in
something very productive (i think the meeting especially the last part was
useful)
The meeting started from the realization that there is an 1% of cases where
the discussion doesn't go well and can get people too emotional, making it not
productive, for the project and for the morale.
Some cases of recent discussions where at first there was disagreement, but
the discussion gone completely smoothly were analized (the 99% when things
goes like they should), such as:
http://old.nabble.com/RFC%3A-Removing-of-decorations-td33476065.html
https://bugs.kde.org/show_bug.cgi?id=302077
some points in common have been individuated:
* we can see in those discussions the tone never escalated, even with
disagreements, they look more like stimulating debates
* when someone wants the mantainer to change his mind stays on exclusively
technical points: raises concerns and arguments them, like needing an use case
for window decoration for remote sessions, that weren't considered in the
original decision
* the maintainer proposes a third solution, balanced between the problem the
original solution tries to address and the problem this causes. like waiting
until a particular lightweight window decoration is here
* The discussion always stays focused, in topic
So that's how we want those discussions to happen.
There can be done a series of recommendations in order to do so, and we can
point to people when those aren't followed.
note that those are just copied/pasted from points made over irc, so if they
are incorrect, not completely understandable or if others missing feel free to
correct:
* we see that there is need to document more
* especially if a discussion turns out to be recurring: document the reasons
and point out to those
* it doesn't need to be done for everything, otherwise becomes not
maintainable with bad signal/noise ratio
* we have established guidelines on how to interact with each other
* we don't want to blame community members for things which happened in the
past
* We concentrate too much on energy eaters, rather than on progress
* we remind each other about our common goals if we see that a discussion goes
in the wrong direction
* there's a lack of trust we need to address
* if anyone breaks the guidelines (whoever they are) breaks these we point it
out, and not write a (more angry) reply which escalates
* code reverting or being a bit invasive in non familiar areas should at least
contact the ML or person affected
* we need a list of component and maintainer
is that started already somewhere?
* we respect maintainer decisions
* and, "respect the elders
* think about the bigger project, if an issue of disagreement risks of
damaging/slowing down the project, is maybe the time to step back and say "i
stil ldon't agree but i respect the decision"
* same thing if the maintainer and/or several other maintainers of related
components didn't change their mind: respect the decision even if you still
disagree
raw mammoth irc log: http://paste.opensuse.org/43938417 (not filtered from ot)
What is missing from this discussion is how to use bugzilla efficiently.
Some recent problems were initiated by bug reports. Bug reports are
users feedback, they are important and the Bug Squad and the Quality
Team can help you if you have any inquiry about it.
Anne-Marie
PS: I'll be away from Sunday 24th June to end of August because of the
kids holiday so I can't maintain Picture Frame during this time and I'll
be happy for any plasma developer to fix any issue they feel should be
fixed.
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
