Update SDV Blueprints Process to be more inline with with Eclipse Foundation Processes

[nacidai]

Some concerns were raised in the sdv-blueprints-dev mailing list (open to committers) for not following the eclipse process to elect new committers to SDV Blueprints. EMO requires new committers to be nominated openly, transparently and based on merit not just recommendations and this poses some difficulty for new blueprints as there is usually no prior code/contributions to refer to.

This issue was opened to capture the discussions and the potential resolution to update the SDV Blueprints process

[nacidai]

The original email from EMO is copied here for our records:

   Dear PMC and Eclipse SDV Blueprints Project team.

  As you know, our open source rules of engagement require that project teams operate in an open, transparent, and meritocratic manner.

  As part of this, elections of both committers and project leads must include a demonstration of merit. Specifically, the nomination statement for an election should provide examples of how the candidate has demonstrated an understanding of the role they're being elected to. This demonstration is for both the project team and for the community.

  Describing what the candidate does or will do within the context of the project is not enough. You'll beed to provide links that prove it.  

  Here are some useful links regarding Committer elections: 
  - https://www.eclipse.org/projects/handbook/#elections-committer
  - https://www.eclipse.org/projects/handbook/#contributing-contributors
  - https://blog.waynebeaton.ca/posts/opensource/hired-a-committer/

  If these candidates are ready to be committers, then it should be easy for you to find some examples of contributions to cite in a merit statement. If there is no public record to cite, then it should be relatively easy for candidate committers to make some meaningful contributions via pull requests that you can cite when you rerun the election later.

  I suggest deleting the election records that you recently opened for Eclipse SDV Blueprints (i.e. Mario Alberto Ortegon Cabrera, Jannis de Veer and Anneke Minke) and would like to invite the project team to restart the election. 

  Let me know if you have any questions.
  Maria Teresa Delgado

[nacidai]

This comment as from @eriksven:

Thank you for the hint. I agree that it looks like we are stretching the Eclipse processes here.

As mentioned by Naci, the idea was that people can propose a new blueprint through GitHub issues and discussions in the community calls and thus already earn the merits to become committer by taking ownership of that blueprint during its creation.

This was agreed to by the project in https://github.com/eclipse-sdv-blueprints/blueprints#process-and-principles-for-new-blueprints.

After revisiting the description, I agree that we should align more with the Eclipse processes and project handbook by considering code contributions for a committer election as well.

Would it be an option to let an existing committer approve the first few contributions to the new blueprint and then start the election for the person who performed the contribution?

Therefore, I would stop the ongoing election process and make the following proposal:

We keep the current process for proposing new blueprints through GitHub issues and presentations in the community call, but we do not automatically start new committer votes. Instead, we still nominate at least one responsible for each blueprint. Then, an existing committer merges the first PRs in collaboration with the blueprint responsible. After a few initial PRs, we can start the committer vote for that responsible person. In most cases, some contributions should come from this blueprint responsible anyway. When there are contributions from other people, we can start additional committer elections.

This way, we ensure that the people who actually develop the blueprint become the responsible and the committer. In the specific case of the insurance blueprint, I am not in doubt, but I have seen a pattern in other projects where managers or product owners, instead of the actual developers, took over the committer role while not contributing any code.

To the point that having more committers avoids friction away from the project: It is still possible to work close to the upstream branch from a fork and through PRs, and we can obviously not make any potential contributor a committer upfront. We should ensure that we do not mix up a regular contributor with the role and responsibilities of committers. Contributions are always welcome, especially from people who are not a committer yet.

What do you think?

Mit freundlichen Grüßen / Best regards

Sven Erik Jeroschewski

[nacidai]

we need to on board at least one nominee as a committer for each repository along with the repo creation. This can be the blueprint coordinator/lead (whoever that might be, but preferably someone from a SDV project). They can take care of the housekeeping required to coordinate the initial commits, pull-requests and nominating the rest of the contributors therefore managing the process. This is the way I imagined to delegate the responsibility of maintaining each blueprint and scale-up, otherwise it will exceed my/or any committers bandwidth as the number of blueprints increase.

[nacidai]

The changes were approved at the Feb 5, 2024 monthly call and the github instructions were BP process is updated accordingly.