Re: [eclipse.org-architecture-council] Eclipse Foundation Development Pr

[Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>]

I've responded to all of the concerns raised in this one note. I hope that this makes sense.

If further discussion is required, may I  recommend that we take that discussion over the issues that I've created to track the changes (or create new issues).

Unfortunately this missed the June call

Sorry about not getting this done in time to add it to the agenda for the June call.

It seems all info under the Reserved section was deleted.

As Gunnar stated, it's a common practice to mark a retire section as "Reserved" to avoid renumbering everything. It also gives us a way of keeping the document anchor in the event that the section is referenced elsewhere. At some point, I'd like to remove the section numbers and make the document more "webby", but let's save that for another day.

Does this mean there is no exception process?

The sentence describes that exceptions are permitted. My preference is to let PMCs decide for themselves whether or not formal process is required.

What does this mean after the deletion? New projects no longer need mentors or they no longer need mentors from the Architecture Council? Please clarify.

The formal concept of mentoring no longer exists. I'm not sure how to clarify this other than to include this a topic in an "office hours" presentation to help folks who have experience with us understand the change. New people to the community will just never have any concept that mentors are required.

The new "unanimous consent" of the PLs to revoke committership. I understand that for removing committers who are disruptive and that there should be some documentation/record that the decision was unanimous. But for simply retiring inactive committers what kind of documentation/record is required to demonstrate unanimous consent?

Whenever committers are retired, some public record of the motivation behind the retirement should be recorded. The specific form of that notice is, IMHO, a matter for the PMC to decide.

 

For example the Eclipse Platform project do a regular review and publicize the intention to retire committers, but there is no documentation that it was unanimous in the past.

The method that the Eclipse Platform uses is a great example of how to do this right (IMHO). I consider lazy consensus to be unanimous. Individual PMCs may set their own definitions.

 

In addition I think this requirement means that projects have to ensure the PLs are updated before they can retire committers for inactivity.

This seems like an obvious requirement to me. If committers are being retired, the PLs should be well-defined, engaged, and involved in the process. Or do I misunderstand your concern?

 

PS the word "retire" only appears in the new changelog entry for this draft of EDP, but "retire" is the word used on the PMI.

Noted. I'll see what we can do to make this consistent.

I recommend that if vulnerabilities are something that are driving this request that you be specific about that in the updates to the text of the EDP. First, this makes at least one of your intentions clear. Second, it communicates a concern to PLs and committers in such a way as to establish high priority.

The draft does explicitly state that the vulnerability reporting policy is one of the triggers for the EMO to unleash these special powers: "This includes, but is not limited to, issues that arise due to a failure to implement the Eclipse Foundation Vulnerability Reporting Policy, the Eclipse Foundation Intellectual Property Policy, the Eclipse Foundation Community Code of Conduct, or other governance policies of the Eclipse Foundation."

I generally try to avoid being too specific in the process document to give us room to adapt to new things. That is, I try to focus on the principle. I purposefully try to keep it open so that we could have the ability to step in in other cases when doing so makes sense. This is why I added the disclosure requirement and reminder that members have the ability to call us out on misuse via the grievance handling process.

HTH,

Wayne

On Wed, Jun 28, 2023 at 12:01 AM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:

AFAICT there's been no response to this note (other than a verbal confirmation from an AC member that they did indeed receive the note).

I'd like to forward this formally to the Board of Directors for their review and approval.

Let this serve as your last chance to raise concerns.

If you've read this over and agree with the changes, please respond to this note with your +1.

Wayne

On Thu, Jun 15, 2023 at 5:03 PM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:

Hey Eclipse Architecture Council.

I've finally gotten around to drafting some changes to the Eclipse Foundation Development Process.

I've posted a draft of the proposed updates and a diff that highlights the changes.

I've set up a milestone in the EDP GitLab repository to track the issues related to these changes.

I've made changes that remove the mentoring requirement for new projects, along with a handful of other changes that you should review. I'd especially like you to look at #12.

I'd like to ship this to the Board of Directors for their approval by the end of the month. I'll send out a follow up request for lazy consensus to pass this to the board after everybody has had a chance to read this over and weigh in with comments, concerns, or questions.

I'm happy to discuss this draft here or in the issues that I've created to track the changes.

Thanks,

Wayne
--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation

My working day may not be your working day! Please don’t feel obliged to read or reply to this e-mail outside of your normal working hours.

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation

My working day may not be your working day! Please don’t feel obliged to read or reply to this e-mail outside of your normal working hours.

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation

My working day may not be your working day! Please don’t feel obliged to read or reply to this e-mail outside of your normal working hours.