Re: [eclipse.org-architecture-council] Eclipse Development Process 2018

[Mickael Istria <mistria@xxxxxxxxxx>]

Hi,

On Mon, Oct 15, 2018 at 5:24 AM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:

Project
A Project is the primary functional unit for open source development, with a dedicated team of developers that work within the bounds of a well defined Scope using infrastructure and services provided by the Eclipse Foundation.

Do project include Top-Level Projects?

Should we mention as a constraint that a project is expected to produce and maintain content (source or specification material at least) that's developed by a dedicated team of developer?

What does "primary functional unit for open-source development" mean? I don't find it explicit enough to be worth being put in the documentation, and I think we could remove it.

Also, what's the value of the "dedicated" term here? It seems to me it could easily be mis-interpreted (at least in French, one could read that those developers are dedicated -spending the vast majority of their time- to the project, or that the project has a dedicated team which can sound like it's a not-so-open team that's not really looking for growth).

About the "using infrastructure and services provided by the Eclipse Foundation", I think it's also misleading as we enable GitHub and TravisCI for instance. I'd suggest something like "Projects are allowed to use the Eclipse Foundation infrastructure and services".

Maybe we can explicitly say "Projects activity is governed by the project team applying the Eclipse Development Process."

According to the answers, I'll try to make a PR.

Release
A Release is a specifically identifiable set of artifacts that are collectively assigned a durable tag in source control and distributed in a semantically versioned durable form of that collection intended by the developers of the project for third-party use.

I've suggested some changes in https://github.com/eclipse-architecture/eclipse-development-process/pull/11 (made directly a PR here as I don't have deeper questions).

> Please provide any feedback or concerns as soon as possible. In order to get this in front of the Board of Directors for approval, we'll need to vote on it during our meeting at EclipseCon Europe next week.

Like Dani said in last call, I don't think requiring a face-to-face meeting to vote that is very fair, as many member won't attend; and I also don't think it's really an agile process. De-materialization just works and it's basically something all our employers try to sell to their customers so we'd better believe in it. Why can't we have an electronic vote when ready? It's way less constraining and takes much less time.

I don't really buy the argument that such AC votes have to happen face-to-face, while other votes in various councils (or even at the Board) can happen electronically by email.

I'll be attending the conference, but I usually have some other meetings that take priority over AC chat. So it's highly probably I don't attend this specific meeting.