| Re: [eclipse.org-architecture-council] Eclipse Foundation Development Process 2023 Update |
Each Project owns and maintains a collection of resources.
Resources may include source code, a Project website, space on the downloads server, access to build resources, and other services provided by the Eclipse Foundation infrastructure. The exact infrastructure provided by the Eclipse Foundation varies over time and is defined outside this process document.
A Project is not strictly required to make use of all the resources made available; a Project might, for example, opt to not maintain a source code repository. Such a Project might operate as an organizational unit, or container, for several Subprojects. Similarly, a Project might opt to provide a consolidated website, build and/or download site for its Subprojects (the Subprojects would then not require those resources for themselves).
Namespaces are assigned to a Project by the EMO. All Project source
code must be organized in the assigned namespaces and Projects can only
Release code under their own namespace (that is, they cannot infringe on
another Eclipse Project’s namespace).
Projects should work with their PMCs and the EMO to request exceptions
to this rule, and with their mentors and PMC if there are questions
regarding the use of the namespace.
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 callSorry 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,WayneOn 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.WayneOn 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.
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/eclipse.org-architecture-council