| Re: [servlet-dev] [ee4j-pmc] Additional spec lead for servlet-api? |
A hearty +1. I have also spoken with Ed Burns and he has agreed to be an informal observer as an engaged individual in the community. Maybe one more familiar face can make a difference? Regardless in the end I understand and respect whatever Greg decides is the best course of action for him. It takes an amount of courage to decide to step down from visible leadership and lead from behind. Reza Rahman Jakarta EE Ambassador, Author, Blogger, Speaker Please note views expressed here are my own as an individual community member and do not reflect the views of my employer. Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone -------- Original message -------- From: Kevin Sutter <sutter@xxxxxxxxxx> Date: 1/27/20 12:33 PM (GMT-05:00) To: servlet developer discussions <servlet-dev@xxxxxxxxxxx> Cc: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx> Subject: Re: [servlet-dev] [ee4j-pmc] Additional spec lead for servlet-api? Thanks, Wayne! I'm hoping that maybe the weekend allowed Greg to reconsider and stay with the Project as co-Lead. --------------------------------------------------- Kevin Sutter STSM, MicroProfile and Jakarta EE architect @ IBM e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter phone: tl-553-3620 (office), 507-253-3620 (office) LinkedIn: https://www.linkedin.com/in/kevinwsutter From: Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> To: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx> Cc: servlet developer discussions <servlet-dev@xxxxxxxxxxx> Date: 01/27/2020 09:43 Subject: [EXTERNAL] Re: [servlet-dev] [ee4j-pmc] Additional spec lead for servlet-api? Sent by: servlet-dev-bounces@xxxxxxxxxxx I'd like to take one more run at this... Project leads are responsible for ensuring that the process is being followed. So, for example, they need to ensure that committers are engaging in the IP due diligence process. But they are also responsible for ensuring that committers are "playing nice". That is, they need to ensure that the level playing field and vendor neutrality bits in the Eclipse Development Process are being observed. Having said that, the Eclipse Development Process says nothing about how teams should organize. As I said earlier, it's natural for leaders to emerge in a community. The authority of those leaders comes from the people in that community. Technical lead (or spec lead) is not a formal position, but it's natural for committers to grow in that role, but an individual only has as much authority in that role as the rest of the committers will grant. So the committers in a project have some say over who their leaders are and what powers they grant. While the role is not specifically defined for this sort of thing, the project lead role could be granted decision making powers. It is completely reasonable for a project team to decide, for example, that somebody in the project lead role must approve of all commits and anybody with that role can mitigate potential rogue actions by rolling back commits. One of the key benefits of organizing in this manner is that project lead is an elected position, so project committers have an explicit means of deciding whether or not they want a particular individual to have those extra powers. On the topic of rogue actions and actors, as the first link in the project leadership chain, one important power granted to project leads by the Eclipse Development Process is the ability to retire committers who are working against the interests of the team. This is a power that should be used with care. While I'm at it, I'd like to also highlight that the Eclipse Development Process says nothing about day-to-day development within a project. It is the project team's responsibility to decide things like development methodology, merit criteria for new committers and project leads, etc.. Greg, I'm dragging my feet on marking you as retired from the project lead role in hopes that you'll reconsider. There's an opportunity here to make the Jakarta Servlet project into an example of how to organize a project team for a successful specification project, and your experience and leadership is a key part of that. HTH, Wayne On Fri, Jan 24, 2020 at 10:50 AM reza_rahman <reza_rahman@xxxxxxxxx> wrote: I am so very sorry to hear this. However, as I have already said, I very much share your concerns and I am not sure I would have felt differently in your position either. Like you, I am not big on navigating invisible relationships. When I can, I try to stick to structure and the demonstrable facts I am fairly sure of. A big danger of invisible relationships is that if you are an "outsider" it may be impossible to ever have any real impact and it won't even matter if the "outsiders" in practice vastly outnumber the "insiders". At least when there is a clear leader with both responsibility and authority, they are accountable to make things truly inclusive and actually listen. There is no such accountability if the entire power structure is submerged out of sight and it is not clear where consensus is supposed to come from. Let's see how it all works out in the end. One can still hope for the best and I am very glad you are still going to be involved. If Ed Burns can be convinced at least to be an observer I will feel even more comfortable with all this. If there is one specification in Jakarta EE that needs to remain relevant it is Servlet. Reza Rahman Jakarta EE Ambassador, Author, Blogger, Speaker Please note views expressed here are my own as an individual community member and do not reflect the views of my employer. Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone -------- Original message -------- From: Greg Wilkins <gregw@xxxxxxxxxxx> Date: 1/24/20 4:05 AM (GMT-05:00) To: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx> Cc: servlet developer discussions <servlet-dev@xxxxxxxxxxx> Subject: Re: [ee4j-pmc] Additional spec lead for servlet-api? 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 _______________________________________________ -- Wayne Beaton Director
of Open Source Projects | Eclipse
Foundation, Inc._______________________________________________ |