3. Contributions
The master branch is set to be a Drupal7 theme with no parent theme.
The omega branch is set to be a Drupal7 theme as a subtheme of the omega4 project.
This branch is used in projectify, so when a new project is scafolded with that tool it is set to use omega as a parent theme.
The nodrupal branch is set to be a standalone theme.
Everything is set up to work exactly the same as the other branches except that it doesn't have the drupal7 files.
This means that it is easy to plug it in afterwards in a drupal7 project, this branch is good for quick mockups and tests outside of drupal7.
The branches are related to one another, the omega and nodrupal branches should always stay ahead, because they have specific code, master gets merged in the two branches after every milestone so that everything is up-to date, omega or nodrupal should never be merged in master, it is custom to this project and can be changed when needed.
Here you can find all the Github documentation.
- Clear Issues (label, assignee, description & title)
-
issue-xpattern for branchnames -
#x: messagepattern for commit messages - Never merge into master, nodrupal or omega on your local machine
- A pull request must be tested and merged by another person
- “Fixes”, “Fixed”, “Fix”, “Closes”, “Closed” or “Close” in the description of pull request
- Correct labels (has-pull-request & others)
Every three weeks we group tickets into important milestones.
It can be that tickets are added or removed from the milestone after discussions, or when critical bugs must be hotfixed.
Here you can find a list of all the milestones.
It is not easy to create issues. Issues should be small and clear tasks, the solution can already be provided by the reporter in the description. An Issue is at it's best when there is an assignee and when it has labels.
Referring to issues can be done with #issuenumber.
Here you can find our label list.
When you pick up an issue and start working on it, you should provide the In progress label, when this label is attached no one else can pick up the ticket in theory.
When you made a pull request that references an issue, it's best to attach the pull requested label, to separate it from the other tickets in the milestone view.
When the Issue is a discussion please attach the label discussion.
For every pull request that is made there should be an issue and it should be referenced from the pull request.
When you are taking an issue that should be in the three branches (for example grunt plugin or configuration), you should start an issue branch from master, when you are ready you can push your issue-... branch to github, then you can make a pull request to master.
Issue branches should be prefixed with issue-...
When you are sure you are doing something specific to the omega or nodrupal branch your issue should start from that main branch. And push the issue like always, to make a pull-request.
Issues should never be merged directly into the main branches!
A pull request must be tested and merged by another person, you can never merge your own issue.
You can close Issues by adding closes #issuenumber, but you can also do that in the description of the pull-request, it is better there because it can be altered afterwards.
More importantly is the commit message structure, #issue: message.
The documentation for making a tag/release can be found here