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

[Mark Thomas <markt@xxxxxxxxxx>]

On 23/01/2020 20:11, Greg Wilkins wrote:
> I have no idea how to reconcile the concept of coming to a consensus vs
> all committers are equal?

It works quite happily for 200+ Apache projects.

> In the IETF model it is the lead that determines if a rough consensus
> has been achieved and thus allow progress to be merged.  But if our
> leads have no special powers and thus cannot rule that a consensus has
> been achieved or not, then any subset of committers can make changes
> without seeking consensus (as has already happened).

Any committer being able to make changes is a *good* thing.

I would like to see as few technical controls as possible put in place
and a much greater reliance on social controls.

I have lost count of the times my work on a Jakarta EE project has
ground to a halt because I can't commit directly to master to fix a
trivial issue and the PR takes days (or even weeks) to be approved.

Committers should be able to identify what commits the community would
just accept (e.g. typo fix) and what needs to be discussed in advance
(API change) and take the appropriate action. And the other committers
should be able to trust them to do that. Yes there is quite a large grey
area between those two. In my experience committers are usually pretty
good at making the right judgement call. The worst case if they get it
wrong is that the change is reverted. I'd expect this to happen more
frequently in the early days as the community figures out for itself
where the line is.

> I'm not advocating that leads are architects, only that they should be
> gateways that can only be passed if a consensus has been reached.

I'd prefer it if there were no gateways.

Mark


> 
> 
> 
> On Thu, 23 Jan 2020, 20:31 Kevin Sutter, <sutter@xxxxxxxxxx
> <mailto:sutter@xxxxxxxxxx>> wrote:
> 
>     It was decided from the very start of EE4J/Jakarta EE that we would
>     no longer have Specification Leads.  Each Eclipse Project needs at
>     least one Project Lead.  But, I have stated over and over again that
>     Project Leads *do not equal*Specification Leads.  Full stop.
> 
>     As far as the list of Committers.  When the Servlet Project was
>     first proposed
>     <https://projects.eclipse.org/proposals/eclipse-project-servlet>,
>     there was a list of proposed committers.  We invited all of the past
>     expert group members.  Plus, each Strategic Member of the Jakarta EE
>     has the ability to appoint a committer representation on each
>     Specification Project
>     <https://www.eclipse.org/projects/efsp/?version=1.2#efsp-committers>.  In
>     addition, there may have been some key industry individuals that
>     were invited to participate.  Actually, since the Spec Lead (Ed
>     Burns) was no longer active on the Project, that's how we ended up
>     inviting you, Greg, and Stuart to be co-Project Leads.  And, that
>     may have also been where some of the "extra" Oracle reps came from. 
>     TBH, I can't remember the exact process for every Project.  But, in
>     the end, anybody could have (and some did) challenge the make-up of
>     the initial committer list before the Project was approved.
> 
>     (Also, just to explain this "appointment" process.. This was put in
>     place to support the Member organizations where the current
>     committer moves onto another job (either inside or outside of the
>     organization).  I'll use IBM as an example.  Martin Mulholland was
>     the JSR expert group member from IBM.  Martin moved onto another
>     role right about the time that these Specification Projects were
>     being proposed at Eclipse.  Thus, we put Paul Nicolluci down on the
>     initial committer list instead of Martin.  Paul has been working on
>     IBM's Web Container solution maybe even longer than Martin did.  In
>     any case, this is why the Member organizations need the ability to
>     appoint a committer to replace exiting committers and still stay
>     involved with the Project.)
> 
>     As Project Leads, you do not have the power to determine who will be
>     or not be a committer.  The set of committers determine that via a
>     vote.  Any committer can nominate another person as a committer, and
>     then the committers can vote on the person based on the stated
>     merit.  Similar to what's happening with the Project Lead vote for
>     Mark right now.
> 
>     I personally don't think you can have too many committers.  That
>     normally means that you have a vibrant community and you all help
>     each other out.  At MicroProfile, we have 54 committers
>     <https://projects.eclipse.org/projects/technology.microprofile/who>.
>      Does it get challenging at times to come to a consensus?  Sure,
>     absolutely.  Is it perfect?  No.  But, at the end of the day, we
>     have a better product.  So, I think we have a good example where
>     having many diverse committers can work and does work productively.
>      The Servlet project needs to try this model before claiming it
>     doesn't work.
> 
>     ---------------------------------------------------
>     Kevin Sutter
>     STSM, MicroProfile and Jakarta EE architect @ IBM
>     e-mail:  sutter@xxxxxxxxxx <mailto:sutter@xxxxxxxxxx>     Twitter:
>      @kwsutter
>     phone: tl-553-3620 (office), 507-253-3620 (office)    
>     LinkedIn: https://www.linkedin.com/in/kevinwsutter
> 
> 
> 
>     From:        Reza Rahman <reza_rahman@xxxxxxxxx
>     <mailto:reza_rahman@xxxxxxxxx>>
>     To:        EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx
>     <mailto:ee4j-pmc@xxxxxxxxxxx>>, Greg Wilkins <gregw@xxxxxxxxxxx
>     <mailto:gregw@xxxxxxxxxxx>>
>     Date:        01/23/2020 12:41
>     Subject:        [EXTERNAL] Re: [ee4j-pmc] Additional spec lead for
>     servlet-api?
>     Sent by:        ee4j-pmc-bounces@xxxxxxxxxxx
>     <mailto:ee4j-pmc-bounces@xxxxxxxxxxx>
>     ------------------------------------------------------------------------
> 
> 
> 
>     To be honest, I mostly agree with Greg here. While the JCP
>     specification lead model had flaws, at least we know for sure it can
>     work. The new model sounds good in theory but no one really knows
>     how it will work in practice. It is a good idea to ease into the
>     ideal view starting from what we know can work in practice.
>     I too am a bit mystified with the whole previously unknown and
>     silent committers in pretty much all of the current projects. I
>     think some practical reconciliation is needed for key specifications
>     like Servlet to move forward confidently.
>     Reza Rahman
>     Jakarta EE Ambassador, Author, Speaker, Blogger
> 
>     Please note views expressed here are my own as an individual
>     community member and do not reflect the views of my employer.
>     On 1/23/2020 12:44 PM, Greg Wilkins wrote:
> 
>     I don't think we have "rouge actors" in the project and I have no
>     reason to doubt the good will of those involved.  The process issues
>     I've complained about were all well intentioned - just uncontrolled.
> 
>     But I do think we have too many committers (13 I miss counted) and
>     to be honest I really don't know who most of them are, or how they
>     got to be committers.  Most were never active on previous servlet
>     expert groups and most are pretty quiet and rarely say anything. 
>      So I really fear how the project is going to work if/when we get
>     onto some real evolution of the project.   The thought that a group
>     of these unknown committers could have as much influence of the
>     future of the servlet-api as Mark, Stuart, Bill and myself is a
>     worry (or perhaps they'll do something wonderful, but it's a risk).
> 
>     I actually would prefer only 5 or 6 committers of those who have a
>     long history with developing the servlet-api, but as that is not the
>     case then I proposed the 3 co-leads as a way to have some
>     structure.  If we only had 5 or 6 active committers, then that would
>     not be necessary.
> 
>     regards
> 
> 
> 
> 
> 
>     On Thu, 23 Jan 2020 at 18:34, Markus KARG <_markus@headcrashing.eu_
>     <mailto:markus@xxxxxxxxxxxxxxx>> wrote:
>     Greg,
>     while I do not see any problem having several project leads, and
>     while I think this is not something the EE4J PMC shoud decide about
>     as it is not a EE4J-specific problem, I'd though like to propose a
>     completely different approach. Just as an idea.
>     In the Eclipse eco system, the role of "Review Team" is to be
>     fulfilled by committers, not by project leads.
>     If you have 15 committers, then you possibly have too much
>     committers which should be simple contributors instead; you do not
>     have too less project leads.
>     It is completely up to your project to decide all about that, but
>     maybe it would be best to simply turn committers into contributors,
>     and have the rest of the committers be the "core review team" then?
>     -Markus
>      
>     *Von:* _ee4j-pmc-bounces@eclipse.org_
>     <mailto:ee4j-pmc-bounces@xxxxxxxxxxx>[mailto:_ee4j-pmc-bounces@eclipse.org_
>     <mailto:ee4j-pmc-bounces@xxxxxxxxxxx>] *Im Auftrag von *Greg Wilkins*
>     Gesendet:* Donnerstag, 23. Januar 2020 18:15*
>     An:* EE4J PMC Discussions*
>     Betreff:* Re: [ee4j-pmc] Additional spec lead for servlet-api?
>      
>     Paul et al,
>      
>     I could not disagree more about the need for a "core review team". 
>      Currently the servlet-api project has 15 committers and we have
>     already had issues where a PR has been made by one, review by
>     another, merged all without knowledge of the spec leads and in a few
>     hours (which were the middle of the night for both spec leads). 
>      We've even had release candidates made in similar ways.   To combat
>     this, we have said that all PRs need approval from a spec lead -
>     thus we have defacto created a core review team.    the proposal to
>     include Mark as a co-lead exactly intended to increase the "core
>     review team".
>      
>     I just do not believe that 15 equal committers can collaborate
>     productively without some structure.   I don't want the old single
>     leader commits everything model, but the 15 equal committers is too
>     far the other way.  We are striving for a happy medium.
>      
>     I'm not sure on what basis the vote should be stopped.  It's been
>     proposed, if the vote gets up, then we have 3 leads. If enough
>     people think it is a bad idea, then the vote wont get up and we'll
>     only have 2 leads.
>      
>     regards
>      
>      
>      
>      
>      
>      
>      
>      
>     On Thu, 23 Jan 2020 at 18:00, Paul Nicolucci <_pnicolucci@gmail.com_
>     <mailto:pnicolucci@xxxxxxxxx>> wrote:
>     Hi,
>      
>     I also agree that 3 leads seems excessive when the primary role of
>     the lead is to be a guiding voice on process rather than making
>     decisions and having some sort of special privilege within the
>     project. If there are specific reviews/work that are required within
>     the Servlet project that man/brain power is required for then some
>     threads should be started in the project in my opinion to get input
>     from the rest of the committers on the project and allow them to
>     offer a helping hand wherever necessary.
>      
>     I think we need to get away from the concept of having a "core
>     review team" and be more transparent within the individual projects.
>      
>     Regards,
>      
>     Paul Nicolucci
>      
>     On Thu, Jan 23, 2020 at 10:19 AM arjan tijms
>     <_arjan.tijms@gmail.com_ <mailto:arjan.tijms@xxxxxxxxx>> wrote:
>     Hi,
>      
>     Though I voted for Mark, based on the fact he's very active and
>     experienced, I do agree with 3 Project Leads being too much.
>      
>     Perhaps in this case Greg might want to step down then?
>      
>     Kind regards,
>     Arjan
>      
>      
>     On Thu, Jan 23, 2020 at 4:50 PM Dmitry Kornilov
>     <_dmitry.kornilov@oracle.com_ <mailto:dmitry.kornilov@xxxxxxxxxx>>
>     wrote:
>     I agree with what Kevin said about a number of leads. One lead is
>     ideal, two is acceptable, more than two is too many. I don’t have
>     anything agains Mark, he is a great project lead, but I think that
>     in order to get him elected someone needs to step out to keep a
>     number of leads reasonable.  
>      
>     I don’t agree with complete elimination of Project Lead role. I see
>     this situation as a consequence of misunderstanding of what project
>     lead role is. We should work more on explaining EDP to committers
>     and make it more clear.
>      
>     - Dmitry
>      
> 
> 
>     On 23 Jan 2020, at 16:25, Ivar Grimstad
>     <_ivar.grimstad@eclipse-foundation.org_
>     <mailto:ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>> wrote:
>      
>     Yes, let's put it on the agenda. I don't think it is a big problem.
>     More a communication thing that we need to continue doing for a
>     while in order to get the thought of a spec lead role to go away.
>     After all, it is 20 years of history we are competing with. It will
>     take some time, but we will  get there :)
>      
>     Ivar
>      
>     On Thu, Jan 23, 2020 at 4:42 PM Kevin Sutter <_sutter@xxxxxx.com_
>     <mailto:sutter@xxxxxxxxxx>> wrote:
>     I guess I was too late with this input since I see that the vote
>     already started...  :-)
> 
>     Ivar,
>     Let's put this on our agenda for our next call.  I'm concerned that
>     this proliferation of Project Leads can be misconstrued as a
>     requirement to make decisions for a given Project.  We need to
>     emphasize that the Project committers and community are key to
>     making decisions.  The Project Leads should be considered
>     "shephards" of the process, not Specification Leads (as in the old
>     JCP definition).  Even the title of this note thread seems to imply
>     "spec leads" vs "project leads".  Thanks.
> 
>     ---------------------------------------------------
>     Kevin Sutter
>     STSM, MicroProfile and Jakarta EE architect @ IBM
>     e-mail:  _sutter@xxxxxx.com_ <mailto:sutter@xxxxxxxxxx>    Twitter:
>      @kwsutter
>     phone: tl-553-3620 (office), 507-253-3620 (office)    
>     LinkedIn: _https://www.linkedin.com/in/kevinwsutter_
> 
> 
> 
>     From:        "Kevin Sutter" <_sutter@xxxxxx.com_
>     <mailto:sutter@xxxxxxxxxx>>
>     To:        EE4J PMC Discussions <_ee4j-pmc@eclipse.org_
>     <mailto:ee4j-pmc@xxxxxxxxxxx>>
>     Date:        01/23/2020 08:10
>     Subject:        [EXTERNAL] Re: [ee4j-pmc] Additional spec lead for
>     servlet-api?
>     Sent by:        _ee4j-pmc-bounces@eclipse.org_
>     <mailto:ee4j-pmc-bounces@xxxxxxxxxxx>
>     ------------------------------------------------------------------------
> 
> 
> 
> 
>     Question...  do you really need a third Project lead to enable these
>     wheels of progress?  Remember, we do not have Specification Leads
>     like we did in the JCP days.  The Project Lead is used to help the
>     project team follow and adhere to the Eclipse processes.  All
>     committers on the Project should have equal footing to enable
>     progress on the Specifications, APIs, and the TCK (if there is one
>     in the Servlet project).  I would really question why a third
>     Project Lead is required.
> 
>     A bit of background...  I know from past experiences both with
>     Jakarta EE and MicroProfile that even two Project Leads is
>     questionable by Eclipse.  But, we have found two Project Leads to be
>     useful to help even the playing field.  For example, with
>     MicroProfile, myself and John Clingan are co-Project Leads.  We
>     communicate on a regular basis and we cover for each other when the
>     other can't do the Project Lead responsibilities due to vacation or
>     other work activities.  We have never entertained the thought of
>     requiring a third Project Lead.  All of the MicroProfile committers
>     chip in to help with the various project responsibilities.
> 
>     One bad example is the EE4J Platform Project.  Here we have six
>     Project Leads.  The reason is that when all of these Projects were
>     getting created for Jakarta EE, we didn't want to spend the time to
>     determine the proper Project Leads.  So, all of the lead
>     organizations ante'd up a person and we all became Project Leads. 
>     Again, I know that Eclipse wasn't thrilled with this approach.  And,
>     we should probably revisit this at some point.
> 
>     So, going forward with nominating another Project Lead is your
>     project's choice.  As Ivar mentioned, it is a required vote among
>     all of the committers on the Servlet Project.  I would just consider
>     whether another Project Lead is really necessary to accomplish what
>     you are looking for.  Thanks.
> 
>     ---------------------------------------------------
>     Kevin Sutter
>     STSM, MicroProfile and Jakarta EE architect @ IBM
>     e-mail:  _sutter@xxxxxx.com_ <mailto:sutter@xxxxxxxxxx>    Twitter:
>      @kwsutter
>     phone: tl-553-3620 (office), 507-253-3620 (office)    
>     LinkedIn: _https://www.linkedin.com/in/kevinwsutter_
> 
> 
> 
>     From:        Ivar Grimstad <_ivar.grimstad@eclipse-foundation.org_
>     <mailto:ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>>
>     To:        EE4J PMC Discussions <_ee4j-pmc@eclipse.org_
>     <mailto:ee4j-pmc@xxxxxxxxxxx>>
>     Date:        01/23/2020 00:46
>     Subject:        [EXTERNAL] Re: [ee4j-pmc] Additional spec lead for
>     servlet-api?
>     Sent by:        _ee4j-pmc-bounces@eclipse.org_
>     <mailto:ee4j-pmc-bounces@xxxxxxxxxxx>
>     ------------------------------------------------------------------------
> 
> 
> 
> 
>     Hi Greg,
> 
>     You can propose a new project lead and start an election among the
>     committers using the committee tools on the servlet project page
>     _https://projects.eclipse.org/projects/ee4j.servlet/developer_
> 
>     Ivar
> 
>     On Thu, Jan 23, 2020, 08:21 Greg Wilkins <_gregw@webtide.com_
>     <mailto:gregw@xxxxxxxxxxx>> wrote:
> 
>     Hi PMC,
> 
>     Stuart and I would like to add Mark Thomas as a third co-lead in the
>     servlet-spec project.  Having the extra man power and a third brain
>     in the core review team would grease the wheels of progress.    What
>     is the process to make this happen?
> 
>     regards
> 
>     -- 
>     Greg Wilkins <_gregw@webtide.com_ <mailto:gregw@xxxxxxxxxxx>> CTO
>     _http://webtide.com_ <http://webtide.com/>
>     _______________________________________________
>     ee4j-pmc mailing list_
>     __ee4j-pmc@eclipse.org_ <mailto: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________________________________________________
>     ee4j-pmc mailing list_
>     __ee4j-pmc@eclipse.org_ <mailto: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_
> 
>     _______________________________________________
>     ee4j-pmc mailing list_
>     __ee4j-pmc@eclipse.org_ <mailto: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_
> 
> 
> 
>     _______________________________________________
>     ee4j-pmc mailing list_
>     __ee4j-pmc@eclipse.org_ <mailto: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_
> 
>      
>     -- 
>     *Ivar Grimstad*
>     *Jakarta EE Developer Advocate | **Eclipse Foundation, Inc.*
>     /_Eclipse Foundation_/ <http://www.eclipse.org/>/: The Platform for
>     Open Innovation and Collaboration/
>     _______________________________________________
>     ee4j-pmc mailing list_
>     __ee4j-pmc@eclipse.org_ <mailto: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_
>      
>     _______________________________________________
>     ee4j-pmc mailing list_
>     __ee4j-pmc@eclipse.org_ <mailto: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_
>     _______________________________________________
>     ee4j-pmc mailing list_
>     __ee4j-pmc@eclipse.org_ <mailto: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_
>     _______________________________________________
>     ee4j-pmc mailing list_
>     __ee4j-pmc@eclipse.org_ <mailto: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_
> 
>      
>     -- 
>     Greg Wilkins <_gregw@webtide.com_ <mailto:gregw@xxxxxxxxxxx>> CTO
>     _http://webtide.com_
> 
>     _______________________________________________
>     ee4j-pmc mailing list_
>     __ee4j-pmc@eclipse.org_ <mailto: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_
> 
> 
> 
> 
>     -- 
>     Greg Wilkins <_gregw@webtide.com_ <mailto:gregw@xxxxxxxxxxx>> CTO
>     _http://webtide.com_
> 
>     _______________________________________________
>     ee4j-pmc mailing list
>     _ee4j-pmc@eclipse.org_ <mailto: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_
>     _______________________________________________
>     ee4j-pmc mailing list
>     ee4j-pmc@xxxxxxxxxxx <mailto: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
> 
> 
> 
> 
> _______________________________________________
> 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
>