| Re: [eclipse.org-architecture-council] Eclipse Development Process 2018 |
|
How about something like this ? Project A Project is a collaborative undertaking of a team of Open Source developers that work within the bounds of a well defined Scope. Project results and artefacts are published as Releases on a regular basis to provide value to users. Projects can use services and infrastructure provided by the Eclipse Foundation. Release A release is the launch of a new version of artefacts providing a combination of features that will provide value to users. For users, it's a promise of new value they can look forward to embedding in their work. For the project team,
a release helps them plan their work. Adopter Adopters are individuals or organisations which start using a new innovation published by a Project. Early adopters are willing to take risks when using the innovation before the majority of adopters starts using the innovation when it has proven maturity. From: <eclipse.org-architecture-council-bounces@xxxxxxxxxxx> on behalf of Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> Greetings Architecture Council. Please see attached the most recent version of the updates to the EDP for 2018. I've used a little diff wizardry to produce a "redline" document that shows the changes. The diff is a bit wonky in places, but I believe that it gets the point
across. I have a one-liner that I'm going to apply to apply pseudo-legal capitalization to the defined terms in the document (e.g. "Release Review" in all occurrences instead of "release review"). I haven't applied that yet. Also, the diff had real trouble with the diagram change that I added, so diffs aren't properly highlighted on the second diagram. I will likely replace the first diagram with something that's more consistent with the way the second diagram
(and the diagrams in the handbook) are rendered. The source is all
here. I have two (fundamental) definitions that I'm struggling with. Any help that you can provide will be appreciated.
The definition of Release in particular feels more cumbersome than it needs to be. Note that these definitions don't necessarily need to be complete: the rest of the document fills in the details. I'm really just looking for a once-sentence
definition. Note that the EDP itself should be agnostic of any specific technology, or notion that the EDP is specifically about "software" (e.g. specifications are not software). I'm also thinking of adding "Adopter" and "User" as terms. Comments welcome. Random thoughts that might spur conversation that leads to valuable changes are also welcome. I intend to push out an update on Monday afternoon that includes the pseudo-legal capitalization, updated project structure diagram, and other minor tweaks after I make another pass. My hope is to push out a final draft on Wednesday. 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. If you can't attend the conference,
please let us know of any concerns Thanks,
-- Wayne Beaton Director of Open Source Projects |
Eclipse Foundation, Inc. Meet us at
EclipseCon Europe 2018:
LUDWIGSBURG, OCTOBER 23 - 25 |