Geir Magnusson Jr. wrote:

On Dec 30, 2003, at 8:37 PM, Harish Krishnaswamy wrote:

Martin Cooper wrote:

This doesn't seem quite right to me.

I agree that when we have voted in a new committer, both the existing

committers and the new committer have had the same expectations with
respect to their rights and responsibilities *within the sub-project*.
While those rights and responsibilities may be the same ones that apply to
members of the PMC, the domain over which they apply is very different.
I don't think it would be right to turn around now, and tell a committer
on sub-project X "oh, by the way, you're now part of the PMC and that
means that you are (collectively) responsible for all of Jakarta". That
doesn't meet the expectations *I* originally had at all, when I first
became a Jakarta committer myself.

Yes, but I thought I had a say, by way of binding votes, in the project I was elected in, and was responsible for the future of the project and now that doesn't seem true either. I haven't been around for too long but this whole thing seems like a problem of misunderstanding of rights and responsibilities. Not that I have a good understanding :)

I think one of the disconnects here is that what we are trying to do is fix an organizational problem to solve a legal issue in order that the legal organization reflects the non-legal reality. Let me try to clarify that babble with a question :

Forgetting about this recent thread of conversation, do you feel that you aren't responsible for and able to affect the future of the projects you are involved in?

I believe and hope the answer is, without thought, "no".

Yes, "absolutely no". My point was, the understanding of committer rights (legally that is), at the time of becoming a committer, was incorrect and so it doesn't matter what we thought or expected. We will just have to make things legally right and realign our expectations accordingly, I think.

The non-legal reality is that you and your community have been working building software, judging commits, electing new committers, etc. Without disturbing anything [as best we can], we want to make things conform to the corporate governance requirements of the ASF.

Absolutely, I totally understand and agree.

It seems that oversight is the only extra responsibility of a PMC member, and it seems oversight is about making sure that contributed code conforms to IP rights. If so, may be somebody has to explain why the CLA is not good enough to ensure the acceptance of this responsibility.

That's an important one, yes. The CLA declares that *you* the committer, to the best of your knowledge, blah, blah... which is one side of the issue. The other side is that 'we the ASF' are also looking out for the ASF re IP rights. So the ASF is able to say 1) we actively are examining IP via the PMC and 2) we require our committers 'examine' IP and certify cleanliness via the CLA. This strengthens the ASF's position that it does everything reasonable.

But another aspect of PMC participation is simply legal detail. As Roy put it (and I'm probably going to bungle this), binding actions of the ASF happen through the structure of the board, officers and the PMCs. Only votes from people on the PMC list are [legally] recognized.

Now, I'm not in any way minimizing the necessity for legal compliance, but I also want to emphasize that "recognized by the community" is just as important, as we'd all just leave and do things elsewhere if it were otherwise.

Absolutely, I totally understand and agree.

I think Ted's proposal is not forcing all committers to become PMC members but rather extending the membership to every one of them and gives them an option to opt out. I don't think there should be any criteria, other than the willingness of the committer, to become a PMC member. This proposal fulfills that and makes the process faster, I think.

While it would make the process faster, I think that the validity of the desired endpoint, a PMC that covers all subprojects well, is path dependent, and the path to greatest defendable legitimacy is when we just don't glom everyone onto the PMC, but ensure that those on it are interested (which the 'opt out' above covers), know what they are doing (via simple educational support) and most importantly, are aligned with the ASF. After all, this *is* a committee of the board of the ASF.

Absolutely, I totally understand and agree. This seems in accordance with Ted's proposal as far as PMC membership is concerned.




PS. I think my thoughts follow the right[eous] path ;)

Foisting additional responsibility on committers doesn't seem like the
right way to go, to me. Allowing - even encouraging - them to take on
the additional responibilities of a PMC member would fit much better with
*my* original expectations, at least.
Martin Cooper

I believe from the ASF perspective




Every time a committer commits, they vote for the code they commit. Most
often, it a vote subject to lazy consensus, and in rare cases it might
not be binding. But, it is vote nonetheless.

Every time a committer commits, they either donate code to the ASF or
facilitate a donation, and they incur the obligation to ensure, to the
best of their ability, that this is IP that can be donated to the ASF.

If we have a committer that does not accept these obligations, then a
misunderstanding has occurred, and such committers should step down. The
ASF does not grant write-access lightly. I think people understand that.

In the normal course, virtually all ASF committers are PMC members,
because its the committers make the decisions and do the work.

It is true that on occasion an ASF committer will not yet be member of
the project PMC. Their votes may not be binding, and their commits will
be scrutinized by PMC members (which is to say other members of the
development team). But, in due course, the PMC that made them a
committer also makes them a member.

When our community elected all of our committers, it was with the
understanding that they were the ones with binding votes, that they were
the decision makers, that the Jakarta Committers were, in practice, the
Jakarta PMC.

In my humble opinion, it is the duty of the PMC to now ratify the
decisions our community has already made. Since we now know that the PMC
is *not* a steering committee and is in fact the active managers of the
codebase, we are obligated to finish the job our community started: give
the committers the legal rights and responsibility that we always
believed they already had.

Make the committers the PMC, because they are the only true PMC that we
have ever had.

Each and every one of our committers have earned their stripe. They have
all proven to the community that they are thoughtful, responsible
self-starters capable of managing our codebase on the community's
behalf. These are the individuals that have been creating, maintaining
and releasing the products we all cherish. These are the individuals
that have been doing the true work of the PMC.

Where things have gone wrong, they have gone wrong because we were still
using a "bootstrap" PMC that excluded all but a few of our decision
makers. I'm sure that there are Jakarta committers that would be
unwilling to serve on a "bootstrap" PMC, but serving on a true,
inclusive PMC may be a different matter.

Right now, the only plan seems to be to nominate committers one-by-one
on the PMC list. I'm just saying that we shouldn't play favorites. I
believe all Jakarta committers have already earned membership in the
PMC; we should tender the offer to every Jakarta committer and let each
decision-maker decide for himself or herself.

If the consensus is that the "bootstrap" PMC will continue to hand-pick
which of our duly-elected committers are promoted to the PMC, and which
are not, then so be it. But, personally, I think that process is nothing
but busy work. The community has already decided. Let's ratify the
community's decisions and let Jakarta be whatever Jakarta wants to be.

But 'nuff said, I have a release to co-manage :)


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to