This repository is used by all members of the Operate First community for managing the ongoing support and sustaining the community of persons and organizations around this initiative.
We plan and keep track of our efforts on the Community Project Board, which is drives the status of the program management page. Feel free to also follow our blog.
This repository (https://github.com/operate-first/community) is the home to efforts to bring a formal community architecture process to the Operate First initiative. The scope of this initiative is large enough with a multi-community impact to warrant going from an organic community effort to a managed community. This initiative is in the beginning stages (bootstrapping) of defining and performing this work.
All are welcome to contribute to this repository and our efforts.
Details beyond this README file can be found in the contributing.md file.
If you are interested in being involved in community projects and meetings make sure to join our Slack and our Operate First Community Google calender to know when we meet.
Until there is a Community Handbook to gather this content within, all of the processes for interacting with this repository and work around it are contained in this section, or held in the contributing.md file.
All commits to this repository should use a pull request process for most changes. This means under normal conditions, no one should commit directly to the repo. Instead, they branch or fork the repo, make changes in the branch/fork, and then make a pull request against the main repo.
Because content in this repo is not in its final form, we do not need as stringent a review process for accepting pull requests into this repo. This repo is for project work that appears in its finished form in locations such as https://operate-first.cloud, https://twitter.com/OperateFirst, the Operate First community mailing list, and so forth. This is generally not a final-form location, and we are often dumping in partially completed work to finish here openly.
However, we want to follow the PR process for several reason:
- it matches practices with the rest of the project;
- it makes sure commits are clean;
- it keeps more people involved and aware of what is happening;
- it helps us keep in the habit.
Early drafts tend to be collaborated on in Google Docs, via email, or on one's own until there is enough material to create a MarkDown file and generate a pull request.
We then work collaboratively in the PR review process to update the content for inclusion in the repo. Sometimes we just touch the work briefly, sometimes we use the PR to edit heavily.
Once in the repo, we use the PR process to ensure commits are clean and things are double-checked. With content, the initial commits are not required to adhere to any style guide. In many cases, that is done during a later review and copyedit pass, to keep the focus on the accuracy and clarity of the content before going to the efforts to make changes for style and final grammar.
This repository uses Prow for CI.
This section is here as a reminder to consider any custom configurations for the .prow.yaml file.
Prow is a CI provider developed for Kubernetes needs. It provides chat-ops management of pull requests, issues, and declarative management for labels, branches, and many more.
We host our own deployment of Prow in Operate First available at https://prow.operate-first.cloud/.
Supported commands are listed here.
We have also enabled Prow to consume on-repository configuration files.
You can specify your config in .prow.yaml.
Additional centralized configuration can be found in the thoth-application repository.
This repository uses the project-wide pre-commit hooks.
We enable yamllint hook by default, since most of our repositories use yaml files extensively.
Default configuration for this hook is located at yamllint-config.yaml.
To install and enable pre-commit locally please follow the instructions here.
It is advised for all contributors to enable pre-commit git hook via pre-commit install after cloning any repo within Operate First.
There are a new set of labels available for the whole Operate First contributor community:
area/community: Indicates an issue/PR is related to the overall community.area/contributorIndicates an issue/PR is related to a project platform contributor.area/user: Indicates an issue/PR is related to a project platform user.kind/experience:Indicates an issue/PR is related to human interaction and experience of the platform, project, et al.kind/governance: Indicates an issue/PR is related to governance.kind/handbook: Indicates an issue/PR is related to a handbook.kind/marketing: Indicates an issue/PR is related to marketing.kind/metrics: Indicates an issue/PR is related to metrics.kind/news: Indicates an issue/PR is related to project news and outreach.kind/onboarding: Indicates an issue/PR is related to onboarding.kind/website: Indicates an issue/PR is related to project web presence.
These labels are common for all projects in the Operate First GitHub repository. This way, wherever you are in the project repos, you can mark a pull request or an issue with these labels to assist in community management.
Non-specific examples:
- A PR that signals the completion of an important Epic worthy of making some noise about and including in a newsletter can be labeled
area/community,kind/news, andkind/marketing. - An issue is related to the experience of users joining the project to become contributors is labeled
area/community,area/user,area/contributor,kind/experience, andkind/onboarding. - A write-up on how to setup a clone of a repository for doing work intended to be contributed to the community would be labeled
area/contributor,kind/documentation,kind/onboarding, andkind/handbook.