Conflict solving and maintainer

[Pierre Stirnweiss]

I am very much in line with what Seb just said in his "philosophical
hike"(c). And it would seem from the previous posts that the current
maintainer bunch do not see themselves as application owners. The later type
of maintainers cannot apply to Calligra because it is not a one-man show
anymore. First there are a huge amount of founding blocks which are shared,
and second, noone can claim to own an application anymore. Even if the
current bunch of maintainers are all in the same line of thoughts, I think
it would still be a good idea to set the rule straight right at the
begining. One never knows what the future is made of, and in a couple of
years time some of the current maintainer might want to step down. It then
would become very relevant that the overall culture of the project makes it
clear what is expected of that role.
I also like the citizenship list idea. In line with this, it perhaps is also
a good idea to drop the name "maintainer" altogether. There are a lot of
strings attached to the term "maintainer" which are not necessarily
applicable here. Perhaps we could rename them as "facilitators".

As for taking lessons from the past and conflict handling, I think that we
should set straight away a mechanism of handling those problems. If we
basically say, we will deal with them when the problems arise and set up
something then, we would basically reproduce what already happened. The
problems would be unhandled until it is too late. I think the biggest
failure of the past was a lack of unanimously accepted way of setting
unsolvable technical disagreement as well as a lack of set consequences for
not respecting the community's decisions and rules (and that also includes
the way people are behaving with others) and no mechanism to enforce this.
I don't think we should be naive enough to think that from now on, there
will never be disagreements which can't be solved between the parties. these
should I think be extremelly rare occurences, but we should as a commnity be
ready to handle them in a commonly accepted way, before they turn poisonous.

Pierre



On Tue, Dec 7, 2010 at 9:49 PM, Sebastian Sauer <mail at dipe.org> wrote:

> On Monday 06 December 2010 17:18:05 Boudewijn Rempt wrote:
> > On Monday 06 December 2010, Mark Kretschmann wrote:
> > > In Amarok, all of our core developers (or "citizens") are basically a
> > > team of maintainers. And we always try to resolve conflicts by
> > > consensus. Only if that fails (very rarely), then we might do a
> > > voting. That happens maybe once a year or so.
> >
> > It depends a lot on the project and what you think the role of
> "maintainer"
> > is. If it's the cerberus who keeps ugly code out, then we can do without.
> > But in the current state, every koffice app needs someone who pulls,
> > pushes, blogs, writes, evangelizes, talks to the press, helps newcomers,
> > does janitorial stuff and keeps an overview of what's going on.
>
> For the record; I did all that without ever being a maintainer of any
> koffice/calligra app. But I am maintainer of a dozend of KDE-applications
> where I did not commit anything for years...
>
> We also have the case that we activly try to move code out of the
> applications
> to share them between different applications. That means that common code
> is
> shared between multiple maintainers what means we don't have one-single-
> maintainer-to-rule-them-all policies there already. In fact during the last
> years that was a big advantage.
>
> I guess it is very important to remove any special-rights someone believes
> he
> earns just cause he has a maintainer-role. This is just not the case. If
> you
> have special-rights then it's so cause all others grant them to you on a
> daily
> temporary base. The maintainer is not some kind of "dictator for live" or
> so
> cause that results in more problems then solutions or at least it has lot
> of
> conflict-potential.
>
> Maintainer means that you identified a single person OR a group of person
> who
> should official be seen as "the guys who know answers to questions, can
> guide
> into the correct direction and maybe even moderate between interests" kind
> of
> introducer/helper/moderator.
>
> I mean let's be serious; how mutch cases do you know where playing the
> maintainer-card was really needed and at how much cases it was providing
> more
> harm then solving problems? If you just look at KDE then the most respected
> core-developers are those who never ever played that card cause they know
> that
> there are better, easier and more promising ways. I see there a clear
> corelation between not playing that card and being respected. That in turn
> means as soon as you play that card you start to lose power rather then
> making
> your point. It's not that different from the atombomb except that noone
> gets
> rich.
>
> So much for my short philosophical hike about maintainers. Sometimes I just
> cannot stop ;) What I like to say with that? Well, I agree with Mark that
> maintainers are not needed but I also don't have a problem with continuing
> using that role as long as it doesn't provide new problems (which I don't
> think it does with the current maintrainers-gang). Personally I like the
> citizen-list idea a lot cause it would 1) allow everybody to participate
> even
> if him/her doesn't have whatever special role and 2) it means majority
> decides
> what is way better then single-person-decisions in any aspect I can think
> of.
>
> Let me add that I would see it was big fail if WMC/CWG is needed any
> longer. I
> am sure we can do much better now just like all other KDE sub-communities
> are
> already able to.
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20101208/9aada833/attachment.htm>