Create/curate an Operate First Community Handbook that is for contributors to guide them and learn from

quaid commented 3 years ago

Anything a contributor needs to know should be included in the Community Handbook, and it can be community maintained used a git-based writing workflow.

Since Op1st is in many ways a meta-community handbook, this concept needs to be considered in the context of this project, rather than creating and maintaining a manual document forever.

We may need to start manually and move to more automated, as we progress.

One question is, how far can a person go as a contributor into the private/root/secret/NOC space underneath the cloud. Operate First needs to consider how to handle those interested in contributing to the projects itself, particularly on the operations side.

If contributions to Operate First itself are desired—which is strongly recommended community best practice—a central contributing guide needs to be created.

Aside from the more obvious git-based contributing method, there will arise people who want to do the hands-on work in the NOC/operations team. If that’s not currently possible, it should be put explained and put on the roadmap for fixing.

Regardless, it is strongly recommended to create an Operate First Community Handbook for documenting the contributor experience.

Anything a contributor needs to know should be included in the Community Handbook.

If anything is missing, when the curious contributor finds the answer, the responsibility is on them to open a merge request with the addition to the Community Handbook.

The Community Handbook can be written in MarkDown or AsciiDoc etc. using a git workflow for managing writing, reviews, and publishing.

sesheta commented 3 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.