Document administrative and development processes

[hoffie]

I think there are some administration-, development- and process-related things which we should document for the whole Jamulus project (code, website, assets).
@gilgongo thankfully already created a placeholder page for that.

I have some more details in my mind, so I'll start with a basic structure and some initial content as a PR as time permits.

I intend to cover the following topics:

• Release process
  • Soft code freeze (no larger changes, nothing translation-related)
  • Hard freeze (no code changes at all)
  • Release shepherd? (What goes into a release, when to cut betas/finals, executing most of the checklist, handling announcements, Changelog)
  • Checklist (or link to an issue template)
  • Versioning
• Translation process
• Tracking Project usage
• PR handling (Who merges? Squash merges OK? Update contributor guidelines!)
• Onboarding, Offboarding (Permission handling, platforms)
• Consensus / Decision making
• Changelog handling (Risk of conflicts with multiple PRs in flight)
• ASIO4ALL / assets hosting

Note:

• The list might sound boring, maybe unnecessary and theoretical, but I'll try to keep the content short and practical.
• For some items we already have established processes, for others I'll propose something.
• For some items there might be better places. And we should move it there.
• Some items may already have been documented elsewhere and could be linked from there.

[ann0see]

Just self assigned this too.

Could you please ping me once you open the PR?

Maybe @ignotus666 also knows some more of the process here.

Also related to gilgongo's work with the clarification of the contribution process.

[hoffie]

Could you please ping me once you open the PR?

Sure, if you get to it earlier, feel free to, but please comment here so that we don't have clashing PRs :)

[ann0see]

Just to briefly document some steps here.

• Release process
  • Soft code freeze (no larger changes, nothing translation-related) (does not seem to exist yet; once we merge the changes from the changes branch to translate, the translate branch is just the state of the changes branch at this time).
  • Hard freeze (no code changes at all) (this is done after everything is merged to the translate{version} branch; changes can still be changed)*
  • Release shepherd? (What goes into a release, when to cut betas/finals, executing most of the checklist, handling announcements, Changelog)
  • Checklist (or link to an issue template) (would be great to have).
  • Versioning (?)
• Translation process (done via three branches; rather complex; documented in the CONTRIBUTING.md file)
• Tracking Project usage
• PR handling (Who merges?) (currently it's mainly me, but this can/should also be changed)
• Onboarding, Offboarding (Permission handling, platforms) (to be discussed)
• Consensus / Decision making (?)
• Changelog handling (Risk of conflicts with multiple PRs in flight) (doesn't exist yet: All changes are part of a PR: Hopefully last PR: Changes to translate for release 3_7_0 #332)

[hoffie]

Thanks! I have clarified the initial issue that the scope is meant to be global -- it should cover both code and website things as they will be identical or at least related in many cases. I just opened the issue in the website repo as that's where the documentation should land.

[gilgongo]

Some of this I think overlaps with what I've been doing on #314

I was waiting for the RC to go out before I made the PR though.