push your branch and submit a pull-request for it;
go through the review process until your pull-request is merged; and
Picking up issues
You should only pick up one issue at a time and must assign yourself to it. Any unassigned issue is up for grabs.
If you can no longer work on an issue, please un-assign yourself.
If someone is already assigned to an issue, do not un-assign them or submit a pull request with work related to that issue.
If you notice the person assigned to the issue hasn't made any updates in more than one week, you can @ them in a comment to check in.
Please note there is no need to ask permission to work on an issue. You should check for pull requests linked to an issue you are addressing; if there are none, then assume nobody has done anything.
Begin to fix the problem, test, make your commits, push your commits, then make a pull request. Mention an issue number in the pull request, but not the commit message. These practices allow for sanity and orderliness for revieweres
confirm if what you want to change is already present in any other branches or forks,
make and test your changes,
if your changes add a new feature or will affect users; update the README.md file
make a branch, push your commits, and a pull request, see Workflow below.
Checklist - maintainer
look for commits after any of these, in either;
master branch of repository at O.S.C.A,
any other branches,
any other forks,
review and merge all pull requests,
apply all desired commits, make pull requests if review is needed,
update the README.md file if necessary,
Open an Issue
We track issues in the GitHub Issues tab of repositories.
An improvement to any of the projects may start with an issue discussion, to build consensus and ensure that work isn't wasted. An issue may be avoided for fixing bugs that are obvious to everyone or part of a project.