Re: [Gdbheads] Re: Feb's patch resolution rate

[Eli Zaretskii]

> From: Elena Zannoni <address@hidden>
> Date: Sun, 28 Mar 2004 12:07:51 -0500
>  > 
>  > It is not unheard of that decisions are taken collectively by a group
>  > of people rather than by a single individual.  That way, the
>  > responsibility rests with that group, but it is not lost.
> 
> Yes, true.  I believe here though we are not talking about a group of
> people making the decision on a patch. We are talking about any one
> person, any global maintainer, doing so. While I see that this can be
> still thought of as a group it is so in a very loose sense. The
> decision about any given patch wouldn't be made by consensus among the
> global maintainers.

I was talking about voting; you seem to be talking about a different
situation.

I believe the case where a single global maintainer approves a patch
not in her area was not meant to be the main method of approving
patches, only a backup, when all else fails.

> If I am responsible for a given area, then I am accountable for the
> given area.  If I do a bad job, I can be called on it.

While true in general, this ``accountability'' has no practical
meaning in our case.  A volunteer cannot be fired or fined, you know.
She can only lose her good name.

> If the "group" does a bad job, who is responsible?

All of them, in the sense depicted above.  I.e., they all lose some
of their good name, and they all get to say the proverbial ``oops''
and publicly slap themselves.

In practice, people tend to approve patches in areas where they feel
they have sufficient knowledge about the subject matter.  For example,
I'd seriously doubt that there's a real danger that a maintainer who
never worked with FRV will approve a patch to FRV-specific files.
This shows clearly, I think, that when we approve a patch, we feel
that our good name is put on the line.  In a volunteer-based project,
this is the equivalent of ``where does the buck stop''.

> Better put, and in more general terms, is this community interested in
> giving credit where credit is due (this is the easy part) and
> correcting problems where they arise (and this is the difficult part)?

Giving credit is important, IMO, but it is secondary to actual
development.  Also, I think a developer who is good at her job will
get credit even if she acts outside of the area of her immediate
responsibilities, or as part of a group.  After all, even if we act as
part of a group, we always act as individuals, and our individual
voice is clearly heard.  Finally, a developer who is active in
approving patches outside her area is probably also active in her own
area as well, so she gets credit there as well.