The intended audience of this document are developers wishing to contribute to the Quarks project.
It provides a basic overview of various aspects of the project below, and uses these overviews as the launching points to other documents which go deeper into the details of each aspect.
Contributing to Quarks Operator
First, thanks for taking the time to contribute to the project!
The following is a set of guidelines for contributing to Quarks Operator. Use your best judgment, and feel free to propose changes to this document in a pull request.
How to contribute
Please do not report security vulnerabilities in public issues!
Instead, report to the CloudFoundry Foundation team first email@example.com and give us some time to fix it in a timely matter before disclosing it to the public. For more information check the CloudFoundry Security page.
Don’t forget to familiarize yourself with our processes and tools, by reading about tooling.
When contributing to this repository, please discuss the changes through an existing Github issue with the core team. We believe it’s the right place to have an open conversation.
Pull Requests are the most well-known way to contribute to any project and they are more than welcome in the Quarks Operator project. Commit messages must be clear and concise to help the reviewer understand what the PR is doing.
The Quarks Operator workload is tracked here. All Github issues are synced with this tracker, so all community issues (either bugs or features) should go to Github.
We want short and accurate templates for different types of issues, to gather required information and to start a conversation. Once again, feel free to improve them by opening a pull request.
How to report a bug
Start by searching [bugs] for some similar issues and/or extra information. If your search doesn’t bring you any help then open an issue by selecting the issue type “Bug” and fill the template as accurately as possible.
How to suggest a feature/enhancement
If you find yourself wishing for a feature/enhancement that doesn’y exist yet in Quarks Operator, start by running a quick [search] - you may not be alone! If you’re out of luck, then go ahead and open a new issue by selecting the “Feature” issue type and answer some needed questions.
How are Github issues handled
When you create a github issue, cf-bot creates a story in the
IceBox board in the tracker automatically
and comments on the issue with the link to the story.
The core team conducts its planning session once every week during which your issue will be discussed.
- If the story is moved to the
Current Iteration/Backlogboard, then expect that the story would be worked on in the coming sprints.
- If the story is left out in the
IceBoxboard itself, then expect that the story low in priority.
- If the github issue becomes stale, it might be closed even though we plan to work on it. The core team will reopen it when work begins.
- Both the github issue and the story will be closed if there is no response for more than 30 days when contacted.
How are tracker stories handled
- By default, a story is in an
- When the developer clicks on the
Startbutton, the story moves to
- When the developer finishes the story, submits a PR and clicks on
Finishbutton, the story moves to
- After approving all PRs that belong to a story, the reviewer and author then try to merge and rebase those PRs, changing references as needed, and ensure all tests are still green. Finally one of them clicks the
Deliverbutton which is when the story moves to the
- The team lead, after checking the feature/bugfix, will accept the story. That is the end of the life of a story. A detailed flow diagram can be found here.
Code review process
The core team looks to Pull Requests regularly and in a best effort.
You can chat with the core team on the Slack channel #quarks-dev, on the Cloud Foundry Slack.
Code of conduct
Please refer to Code of Conduct