Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [servlet-dev] [ee4j-pmc] Additional spec lead for servlet-api?

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



Back to the top