This is an old revision of the document!
Fuel@OPNFV Work procedures and guidelines
Code of conduct
To follow the rules of conduct are essential to ensure good and fruitfull collab
oration:
Be open: We invite anyone to participate in any aspect of our projects. Our community is open, and any responsibility can be carried by a contributor who demonstrates the required capacity and competence.
Be considerate: People use our work, and we depend on the work of others. Consider users and colleagues before taking action. For example, changes to code, infrastructure, policy, and documentation may negatively impact others.
Be respectful: We expect people to work together to resolve conflict, assume good intentions, and act with empathy. Do not turn disagreements into personal attacks.
Be collaborative: Collaboration reduces redundancy and improves the quality of our work. We strive for transparency within our open source community, and we work closely with upstream developers and others in the free software community to coordinate our efforts.
Be pragmatic: Questions are encouraged and should be asked early in the process to avoid problems later. Be thoughtful and considerate when seeking out the appropriate forum for your questions. Those who are asked should be responsive and helpful.
Step down considerately: Members of every project come and go. When somebody leaves or disengages from the project, they should make it known and take the proper steps to ensure that others can pick up where they left off.
Commit procedures
Any contributor may commit code to the fuel@OPNFV repository.
Keep related/cumulative patches together in one and the same patch-set - git commit –amend
Use topic branches for patch sets, i.e. create- and work on a local branch for the patch-set - git branch my-bug, git checkout my-bug, create the patch, git add …, git commit -s, git review
Code commit messages shall follow the following format:
MERGE/DO NOT MERGE - indicates weather the intention is to merge the commit
VERIFIED/NOT VERIFIED - indicates weather the commit has passed the developers pipeline verification.
JIRA: jira # - indicates the JIRA ID which the commit reffers to, use BUG as a JIRA reference if it reffers to a non reported bug.
DESCRIPTION: A short commit description
Review procedures
Contributors can vote -1,0,+1, committers can vote -2,-1,0,1,+2
U * se -2 if you know the patch would not work or would interfere with other functionality, a review comment is mandatory.
Use -1 if you don't agree with the patch, or if there are improvements that you want made, a review comment is mandatory
Usee 0 if you just want to communicate through the comment field, 0 without any comments doesn't make sense and shall be avoided.
Use +1 if you agree with the patch, don't vote +1 on your own patches.
Use +2 if you agree with the patch and want it merged, don't vote +2 on your own patches unless the project lead agrees and don't vote +2 until a chorum has voted +1 or a 24 hour period has passed.
Verifying your