Firstly, thanks for these emails Sandy. It's a good wake up call for me,
and I should explain why I'm being so anti-community.
We're out of sync with the ASF - I'm pretty confident that the view that
was reached a few years ago that Jakarta should not be a huge umbrella has
not changed. If anything it has been strengthened by time and the
weakening of the Jakarta community.
The chair role is that of a bridge. They must pass information to the
board/ASF from the community, and to the community from the board/ASF. My
pushes for reforming how do we do things are the latter - they're my
ideas, but I check every now and then informally with other asf members
(individually and via the members IRC channel) to make sure I'm not going
too far. Hopefully you'll see that I'm not that tied to my ideas - if
there's not a lot of interest, I'll dump them and come up with new ones :)
The other half is to then see what conversations happen and consensus
builds. People are quite against moving votes to a common list for
example, but they're less against having no walls in svn (just a couple of
-1 opinions so far). So I'll be dropping the former and asking for votes
on the second.
And yes, I don't know what I'm doing :) We're pretty good at having unique
problems in Jakarta - I don't think Web Services and XML have quite the
separation of internal communities that we have.
One possible consensus may have been that we wanted to remain separate -
in that case I'd have to be asking the board for a whole series of
different things. If we remain highly separate, I think we need to be able
to delegate subproject oversight far more clearly than we have so far -
and that's something we pretty much decided not to do a few years ago when
there was lots of debate. As it is, I think we're pretty split on the
separate bits, and new TLPs are probably a better solution to some of
those desires to remain independent.
Not that the above is meant to be complaints - this stuff is very
interesting to be thinking about; but hopefully it gives you a bit of an
idea of my reasons and direction so it seems less sly.
Replying inline about the particular issue:
On Thu, 16 Mar 2006, Sandy McArthur wrote:
On 3/16/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
I can definitely do this - just trying to avoid that much work and spam to
the mail lists as I think I would need to cc pmc@ or general@ on each
email - though I could do one big cc: email each week interval.
If consensus prefers this, I'll definitely work at finding time to go
ahead and do it.
In my mind it is the right thing to do regardless of general
consensus. If you are going to strip someone of their title or
responsibilities without previously agreed terms or making an
reasonable effort to directly resolve the issue with them, then it's
wrong and disrespectful.
The biggest problem I have with it is that it forces me to come up with a
list of people to exclude - that's the one that feels wrong to me. Let's
say, anyone who hasn't committed since 2004. They might not commit, but
they may still listen to the pmc@ mailing list and say something every now
and then.
So let's say everyone who has not emailed since 2004 and not committed
since 2004. And that still doesn't cover those who have not been reading
email since 2004 - as that's an impossible list to make.
I agree with one of your points - not telling them before removing them is
definitely wrong. However I don't think your solution is right. Rather we
should:
* Do the SVN file to create a list of people who are not actively
fulfilling their responsibility as a member of the PMC (ie paying
attention).
* Post the list of those not in the SVN file to the PMC list for any -1s
and reasons as to why they'd be
* Inform each PMC member of the removal (I can repeat if felt necessary).
* Wait a period of time. 1 month, 2 months, 3 months?
* Remove from PMC. Record who was removed so we know who to be able to
quickly add back in. Martin mentioned that 72 hours meant they could miss
the vote they're interested in - yep, c'est la vie.
It may turn out that everyone shows that they are active and that we
really do have an active PMC that is three times larger than the next (or
double or something like that). In that case, I'll be able to happily tell
the board that that is so and we'll have underline the importance of
paying attention to the shared community mailing lists.
Introducing a new tasks that only your buddies will likely know about
in order to maintain membership feels a bit like when the south (in
the USA years ago) introduced literacy tests to keep blacks from
voting.
It's fine that you have an agenda, but be straight forward and honest
about it. And don't make people jump through hoops so their possibly
conflicting positions are still binding.
Hope I'm not coming across like this.
My buddies in this case are described as: "People who read Jakarta mailing
lists". Ideally pmc@ and general@, though I can quite happily mail all the
-dev lists if we think there are pmc members not listening to the central
lists.
My example included a little exaggeration to make it more obvious. I
don't actually equate being a PMC with what I consider a human rights
issue.
But yes, it does seem like your avoiding the effort required to do the
right thing and in the process it comes off a little underhanded.
Avoiding bureaucracy where we can is important though - the chair role is
not meant to be a managerial pen-pusher role; it's just a developer who
organizes a report every 3 months. One of the problems (I reckon) with the
disjoint umbrellas is that it turns their chairs into pen-pushers. Useful
for us coders who don't want a management job at work and yet are
interested in the experience - it's not something you can get in very many
places in open-source; but not a particularly good thing for the project.
My agenda is to make things less messy. Am working hard to avoid taking
the direction of introducing small changes to lead the community in a
direction. That'd be the dishonest bit.
I guess this does have some link to my agenda to enforce the single
Jakarta community meme
I generally don't have a problem with administrative goals, I'm mostly
indifferent to all of them. I care about the code, the end user's
experience, and my user experience. I will say I think ratio of
administrivia emails and commit log emails is out of balance.
Administrative tasks are important but not so much to justify a
bureaucracy and kill productivity.
+1. This is a tenet of the ASF - the foundation exists to improve the
productivity of the community development. A single shared mail admin
saves us all having to handle it ourselves, etc etc.
In a flat project - I think the admin tasks to commit log ratio is in
balance - (those chairs with experience of other TLPs, any thoughts?) -
but with us it is out of whack.
- but even in the multi-community meme, there'd be
no excuse for pmc members not being on general@ and [EMAIL PROTECTED]
A pmc member who is not on pmc@ (and doesn't want to subscribe) has
effectively resigned in my view; pretty much the same for [EMAIL PROTECTED]
I can agree with that but unless that is made clear when someone is
made a PMC. I'm not a PMC so I don't know. If the duties and
expectations of a PMC don't include being responsive on a mailing list
then changing the rules without their consent isn't right.
It's not a rule - there are no written down rules that I know of for what
a PMC member should do (that'd be unnecessary bureacracy). However, the
point of a PMC is oversight - and if you're not looking you're not doing
oversight. So I don't think it's too harsh a point of view.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
