Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] Eclipse Foundation Development Process 2023 Update
Hi Wayne,

No problem :). Removing the whole paragraph is a better idea. Thank you for looking into it!

Emily

On Tue, Jul 4, 2023 at 11:09 PM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:
I realise now that I misunderstood your concern, Emily. My apologies.

Upon closer inspection, I actually find the entire paragraph problematic and am inclined  to strike out the whole thing, leaving it as a matter between the project and their PMC. Even adding the removed sentence back in doesn't actually solve the problem: that sentence is passive and doesn't clearly state that exceptions are actually permitted.

I need to move this forward and would very much like to avoid doing another iteration at this point.

In that spirit, I will suggest that while assigning the namespace, the EMO takes the project's needs and the opinions of the PMC into consideration to grant the greatest amount of latitude possible for the context, and that the grievance handling process is available in the event that the EMO oversteps. I'll further suggest that as it exists now, there is nothing stopping the EMO from changing a decision. Finally, once we actually strike this sentence out, the potentially bad behaviour that it is trying to prevent is covered by the "EMO Responsibility" section (I believe that we could argue that irresponsibility infringing on another Eclipse project's namespace would fall into the category of "practices that risk harm to Eclipse Projects").

I've created an issue to track removing this paragraph.

Once again, Emily, I'm sorry for having read your comments too quickly and not properly understanding your concern before responding.

Wayne



On Thu, Jun 29, 2023 at 9:45 AM Emily Jiang via eclipse.org-architecture-council <eclipse.org-architecture-council@xxxxxxxxxxx> wrote:
Hi Wayne,

Thank you for your detailed explanation! I still think removing the exception clause made me feel there is no exception.

4.2 Code and Resources

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.


When you read the last paragraph, with the "must" , "can only" in the sentence, it suggests there is no exception. I prefer not to delete the strike-through sentence if we allow such an exception unless there is a legal reason to do so.

Thanks
Emily

On Wed, Jun 28, 2023 at 7:43 PM Wayne Beaton via eclipse.org-architecture-council <eclipse.org-architecture-council@xxxxxxxxxxx> wrote:
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 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


--
Thanks
Emily

_______________________________________________
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


--

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.



--
Thanks
Emily

Back to the top