[
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,
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.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/kevinwsutterFrom:
Wayne
Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>To:
EE4J
PMC Discussions <ee4j-pmc@xxxxxxxxxxx>Cc:
servlet
developer discussions <servlet-dev@xxxxxxxxxxx>Date:
01/27/2020
09:43Subject:
[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,
WayneOn 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 RahmanJakarta EE Ambassador, Author, Blogger,
SpeakerPlease 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
_______________________________________________
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
-- Wayne
Beaton
Director
of Open Source Projects | Eclipse
Foundation, Inc._______________________________________________
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