Open Source Contribution Standards

I’d like to start a discussion that yields a standard set of contribution standards for the UAVCAN reference implementations. These standards would be prepended to all CONTRIBUTING.md files in our repositories. I’ll open the conversation in this thread and we’ll see if we can forge the text here otherwise we’ll digress to a collaborative tool like googledocs.

I’ll start with starting points. There are several templates out there we can look at:

Code of Conduct

Contribution Standards

My initial proposal is the have a CODE_OF_CONDUCT.md and a standardized CONTRIBUTING.md preamble that we add to all of our reference implementation repositories (i.e. not the standard repo nor the public datatypes).

For CONTRIBUTING here’s a strawman outline:

Contributing Guidelines

(welcome text)

Ground rules & expectations

This project has adopted the (insert decision here and link to CODE_OF_CONDUCT.md).

Security issue notifications

If you discover a potential security issue in this project we ask that you (do something here)

Community

(blurb about forums and the consortium)

How to contribute

How to get started as a regular contributor

(todo: how to find good first issues, submit your first PR, and generally participate in ongoing development)

Reporting Bugs/Feature Requests

(our standards for using github issues)

Contributing via Pull Requests

(our PR procedures and standards)

How to contribute a project or become a maintainer

(todo: our process for interning and electing maintainers)
(todo: our process for accepting a new project)

Coding Style

(let the style wars begin!)

Setting up your environment

This is the end of the preamble. Each project would then append the project-specific developer environment text. Most of our projects already have this text.

This is a sensible initiative but I would narrow the scope a bit.

Ground rules & expectations

Let’s omit this section for now and focus on more tangible issues at hand.

Security issue notifications
If you discover a potential security issue in this project we ask that you …

…email maintainers@uavcan.org (which is an alias for consortium@uavcan.org).

Coding Style

  • For Python projects we could limit ourselves to two rules: follow PEP8 and use Black with line-length = 120.

  • For C++ we could copy the prior Zubax syle doc somewhere (like this forum) and call it the UAVCAN style. Would that be acceptable?

As for the other items, I agree with the general direction, let’s discuss the specifics as we go.