Re: [servlet-dev] [ee4j-pmc] Additional spec lead for servlet-api?

[Greg Wilkins <gregw@xxxxxxxxxxx>]

Dmitry,

I don't think I'm emotional nor over reacting.  I truly don't understand how I can lead a project in this process that I don't really understand how it's meant to work.  I know it can be done, as there are many examples of projects that work well that way... just not ones that I've been involved with!  

I'm not worried about rogue elements.  I'm worried about factions that genuinely believe they are following the process, who think they have a consensus and merge... only for another faction that genuinely believes they are following the process  and that they have a consensus to revert.  You don't need bad actors for it to go off the rails.  The histories of the servlet and HTTP specifications are littered with such disputes, so it is highly possible for new ones to emerge and as a leader in the EDP as described, I just don't feel armed with the tools I personally would need to address such disputes.

Personally I like having a structure that gives somebody both the responsibility and authority to resolve such factional differences by striving for a rough consensus and I just feel lost whenever there is no such structure and to me if feels like belligerence, oh I mean persistence can be over rewarded.   Others appear to thrive in such an environment and I'm sure they can do a fine job of it. If I had realized initially that was the style of project the PMC wanted, I would never have agreed to be lead in the first place.  Leading a process you don't understand how it's meant to work is a recipe for failure.

I'm not saying the process is wrong. I'm saying it is wrong for me and that there are more suitable people to lead.  I'm happy to contribute on a technical basis as a committer and if the process is as you describe, then there is nothing I could do a leader that I can't do as a committer.

cheers

 

On Fri, 24 Jan 2020 at 13:17, Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:

Greg,

This conversation is getting a way too emotional without a reason. You are overreacting.

There are inactive committers in all projects and it cannot be avoided. EclipseLink has much more inactive folks than Servlet. I was bothered with it at the beginning too. When I realised that it doesn’t affect work we are doing, I stopped worrying about it.

One of the reasons why EE4J projects have many inactive Oracle committers is that most of the projects were previously owned by Oracle. Oracle is a big company. People are coming and going. People are tossed between different projects. All those folks were involved in technical work required during the transition process such as addressing legal issues, working on new CI/CD pipelines, etc. Some of them are not involved anymore, but there are still committers. It wouldn't be possible to finish the transition on time without getting committer access.

On the other hand, we are talking about some hypothetical “rogue committers” situations, which may happen but haven’t so far. As Ed mentioned, EDP has some process of dealing with it. If you disagree with some changes merged you can always reopen the discussion, put it on vote and rollback the PR if all agree. Or you (project) can setup some review rules. It’s how it works and it’s different from JCP rules and from rules enforced by employers.

Thanks,
Dmitry


> On 24 Jan 2020, at 10:04, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:
>
>
> All,
>
> I think we are all in agreement about how an OSS project should operate as an open, consensus based meritocracy.  But we do not agree as to how to actually achieve that with the EDP.   So for those that want to skip the lengthy response below, the tl;dr; is that I am resigning as project-lead of the servlet-api project.  This is not a F-you-all nor a vote of no confidence, just a realisation that I personally am not the right person to meet the PMCs expectations of the servlet-api project lead.
>
> How can you have a meritocracy if those with merit have no more "cracy" than mostly inactive corporate appointees with patent grants?  How can there be consensus if there is no one to adjudicate that a consensus has been achieved (or not)? How can the process be considered open if such questions are only resolved by a web of informal influencer relationships?  Is it really that the EDP is that projects are to be governed by vibe? 
>
> If being a project lead really carries no sense of actual leadership, then why burden our de facto leaders with the role of project lead?  They are precisely the ones we need to empower as much as possible to deal with name-aggedon and rebuilding our brand in the post apocalypse (or green fields depending on your point of view) name space we are heading to. 
>
> I was under the misapprehension that the project lead's role was to use their experience and judgement to ensure that consensus based meritocracy approach was achieved and I wanted to be more inclusive in how that was enforced in the servlet-api project. I see now that my desire to appoint Mark as a third co-lead was an attempt to formalise the meritocracy that already exists informally in the servlet-api project.  I don't always agree technically nor on process with Mark, but I really respect the way in which he approaches such discussions and thought it would be good to have him more involved on the process side of things. But clearly such an attempt to formalise the enforcement of process is an anathema to the PMC and EDP.
>
> I have always been drawn more to the IETF model, where a WG chair(s) has both the responsibility and the authority to ensure a fair and open process is followed - I've not always liked the outcomes but I could never fault the process.  I've always had trouble with the Apache-style approach as there is no formal open structure and you have to somehow sense the informal social web of influencers of which I'm mostly oblivious (in real life as well ).  My subjective observation is that there are some communities that thrive in Apache-style, but that there is also a significant non-empty set of communities that fail/fracture/fork.  I guess if I was a member of the first set,  then my efforts to contribute Jetty to Apache (several decades ago - prior to the creation of Tomcat) would not have failed.  So it is my personal preference that I wished the servlet-api group to be more IETF and less Apache.  Obviously this is at odds with the PMCs desires.
>
> I clearly do not understand how the PMC wishes the EDP to be actually implemented as I fundamentally do not understand how a project lead can ensure an open consensus based meritocracy if they have no power to actually enforce process.   If an EDP project lead is merely a bureaucrat and true leadership is left to opaque informal relationships between formally equal committers not necessarily appointed by merit, then I'm not the right person to be a servlet-api project lead, as whatever my strengths are they do not include dealing with bureaucracy nor dealing opaque webs of informal power relationships (no I probably don't know WHO you are!).
>
> The lack of a formal structure has been a concern of mine for some time and now that I see it is by design rather than acident, I think it is best that I resign my position as servlet-api co-lead.... and just to prove I have no idea of how the eclipse bureaucracy works... how do I formally do that???
>
> Note that I intend to remain fully engaged with the servlet-api project and think my nomination of Mark was inspired as his Apache background should make him very suitable to lead the Apache-style process that the PMC desires.  I hope to watch and learn how the Apache style can be successful as it has obviously been so in many other projects.
>
> regards
>
> _______________________________________________
> ee4j-pmc mailing list
> ee4j-pmc@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/ee4j-pmc

_______________________________________________
servlet-dev mailing list
servlet-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/servlet-dev

--

Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com