docs: Update CONTRIBUTING, README
Moved CONTRIBUTING file to root folder, updated CONTRIBUTING and README, e.g. adding release history section; referring to Jira and Slack instead of Github issues and Gitter; adding a section on Jira life cycle; and more FIXES: WEB-123, WEB-124, WEB-125
This commit is contained in:
steinwinde
@@ -1,46 +0,0 @@
|
||||
# Code of Conduct
|
||||
|
||||
## Our Pledge
|
||||
|
||||
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
|
||||
|
||||
## Our Standards
|
||||
|
||||
Examples of behavior that contributes to creating a positive environment include:
|
||||
|
||||
- Using welcoming and inclusive language
|
||||
- Being respectful of differing viewpoints and experiences
|
||||
- Gracefully accepting constructive criticism
|
||||
- Focusing on what is best for the community
|
||||
- Showing empathy towards other community members
|
||||
|
||||
Examples of unacceptable behavior by participants include:
|
||||
|
||||
- The use of sexualized language or imagery and unwelcome sexual attention or advances
|
||||
- Trolling, insulting/derogatory comments, and personal or political attacks
|
||||
- Public or private harassment
|
||||
- Publishing others' private information, such as a physical or electronic address, without explicit permission
|
||||
- Other conduct which could reasonably be considered inappropriate in a professional setting
|
||||
|
||||
## Our Responsibilities
|
||||
|
||||
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
|
||||
|
||||
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
|
||||
|
||||
## Scope
|
||||
|
||||
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
|
||||
|
||||
## Enforcement
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at info@mifos.org. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
|
||||
|
||||
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
|
||||
|
||||
## Attribution
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
|
||||
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
|
||||
|
||||
[homepage]: https://www.contributor-covenant.org
|
||||
@@ -1,187 +0,0 @@
|
||||
# Getting Started
|
||||
|
||||
- View the [README](../README.md) or [watch this video](https://youtu.be/OnxxC3K2oro) to get your development environment up and running.
|
||||
- Learn how to [format pull requests](#submitting-a-pull-request).
|
||||
- Read how to [rebase/merge upstream branches](#configuring-remotes).
|
||||
- Understand our [commit message conventions](https://github.com/openMF/web-app/blob/master/.github/COMMIT_MESSAGE.md).
|
||||
- Sign our [Mifos CLA](http://mifos.org/about-us/financial-legal/mifos-contributor-agreement/).
|
||||
- Follow our [code of conduct](CODE_OF_CONDUCT.md).
|
||||
- [Find an issue to work on](https://github.com/openMF/web-app/issues) and start smashing!
|
||||
- [Ask a question on Gitter](https://gitter.im/openMF/web-app).
|
||||
- Learn more at our [getting started guide](https://mifosforge.jira.com/wiki/spaces/RES/pages/464322561/New+Contributor+Getting+Started+Guide).
|
||||
|
||||
# Contributing Guidelines [](https://github.com/openMF/web-app/issues)
|
||||
|
||||
When contributing to this repository, please first discuss the change you wish to make via an issue.
|
||||
|
||||
Make sure you read the [Wiki](https://github.com/openMF/web-app/wiki).
|
||||
|
||||
Do not open issues for general support questions as we want to keep GitHub issues for bug reports and feature requests. If you have got any questions, please email to our [mailing list](https://sourceforge.net/projects/mifos/lists/mifos-developer). You can also join our [gitter channel](https://gitter.im/openMF/web-app) to chat about your queries in real-time.
|
||||
|
||||
Each active repository has its own channel to direct questions to. Also join the [official gitter channel](https://gitter.im/openMF/mifos) of Mifos.
|
||||
|
||||
Remember that this is an inclusive community, committed to creating a safe, positive environment. See the whole [Code of Conduct](CODE_OF_CONDUCT.md) and please follow it in all your interactions with the project.
|
||||
|
||||
## Submitting or Requesting an Issue/Enhancement
|
||||
|
||||
### Best Practices for reporting or requesting for Issues/Enhancements:
|
||||
|
||||
- Before you submit an issue, please search the issue tracker, maybe an issue for your problem already exists and the discussion might inform you of workarounds readily available.
|
||||
- Follow the Issue Template while creating the issue.
|
||||
- Include Screenshots if any (specially for UI related issues).
|
||||
- For UI enhancements or workflows, include mockups to get a clear idea.
|
||||
|
||||
### Best Practices for getting assigned to work on an Issue/Enhancement:
|
||||
|
||||
- If you would like to work on an issue, inform in the issue ticket by commenting on it.
|
||||
- Please be sure that you are able to reproduce the issue, before working on it. If not, please ask for clarification by commenting or asking the issue creator.
|
||||
|
||||
**Note:** Please do not work on an issue which is already being worked on by another contributor. We don't encourage creating multiple pull requests for the same issue. Also, please allow the assigned person at least 2 days to work on the issue (The time might vary depending on the difficulty). If there is no progress after the deadline, please comment on the issue asking the contributor whether he/she is still working on it. If there is no reply, then feel free to work on the issue.
|
||||
|
||||
## Submitting a Pull Request
|
||||
|
||||
### Best Practices to send Pull Requests:
|
||||
|
||||
- Fork the [project](https://github.com/openMF/web-app) on GitHub
|
||||
- Clone the project locally into your system.
|
||||
|
||||
```
|
||||
git clone https://github.com/your-username/web-app.git
|
||||
```
|
||||
|
||||
- Make sure you are in the `master` branch.
|
||||
|
||||
```
|
||||
git checkout master
|
||||
```
|
||||
|
||||
- Create a new branch with a meaningful name before adding and committing your changes.
|
||||
|
||||
```
|
||||
git checkout -b branch-name
|
||||
```
|
||||
|
||||
- Add the files you changed. (avoid using `git add .`)
|
||||
|
||||
```
|
||||
git add file-name
|
||||
```
|
||||
|
||||
- Follow the style conventions for a [meaningful commit message](COMMIT_MESSAGE.md).
|
||||
|
||||
```
|
||||
git commit
|
||||
```
|
||||
|
||||
- If you forgot to add some changes, you can edit your previous commit message.
|
||||
|
||||
```
|
||||
git commit --amend
|
||||
```
|
||||
|
||||
- Squash multiple commits to a single commit. (example: squash last two commits done on this branch into one)
|
||||
|
||||
```
|
||||
git rebase --interactive HEAD~2
|
||||
```
|
||||
|
||||
- Push this branch to your remote repository on GitHub.
|
||||
|
||||
```
|
||||
git push origin branch-name
|
||||
```
|
||||
|
||||
- If any of the squashed commits have already been pushed to your remote repository, you need to do a force push.
|
||||
|
||||
```
|
||||
git push origin remote-branch-name --force
|
||||
```
|
||||
|
||||
- Follow the Pull request template and submit a pull request with a motive for your change and the method you used to achieve it to be merged with the `master` branch.
|
||||
- If you can, please submit the pull request with the fix or improvements including tests.
|
||||
- During review, if you are requested to make changes, rebase your branch and squash the multiple commits into one. Once you push these changes the pull request will edit automatically.
|
||||
|
||||
## Configuring remotes
|
||||
|
||||
When a repository is cloned, it has a default remote called `origin` that points to your fork on GitHub, not the original repository it was forked from. To keep track of the original repository, you should add another remote called `upstream`.
|
||||
|
||||
1. Set the `upstream`.
|
||||
|
||||
```
|
||||
git remote add upstream https://github.com/openMF/web-app.git
|
||||
```
|
||||
|
||||
2. Use `git remote -v` to check the status. The output must be something like this:
|
||||
|
||||
```
|
||||
> origin https://github.com/your-username/web-app.git (fetch)
|
||||
> origin https://github.com/your-username/web-app.git (push)
|
||||
> upstream https://github.com/openMF/web-app.git (fetch)
|
||||
> upstream https://github.com/openMF/web-app.git (push)
|
||||
```
|
||||
|
||||
3. To update your local copy with remote changes, run the following: (This will give you an exact copy of the current remote. You should not have any local changes on your master branch, if you do, use rebase instead.)
|
||||
|
||||
```
|
||||
git fetch upstream
|
||||
git checkout master
|
||||
git merge upstream/master
|
||||
```
|
||||
|
||||
4. Push these merged changes to the master branch on your fork. Ensure to pull in upstream changes regularly to keep your forked repository up to date.
|
||||
|
||||
```
|
||||
git push origin master
|
||||
```
|
||||
|
||||
5. Switch to the branch you are using for some piece of work.
|
||||
|
||||
```
|
||||
git checkout branch-name
|
||||
```
|
||||
|
||||
6. Rebase your branch, which means, take in all latest changes and replay your work in the branch on top of this - this produces cleaner versions/history.
|
||||
|
||||
```
|
||||
git rebase master
|
||||
```
|
||||
|
||||
7. Push the final changes when you're ready.
|
||||
|
||||
```
|
||||
git push origin branch-name
|
||||
```
|
||||
|
||||
## After your Pull Request is merged
|
||||
|
||||
After your pull request is merged, you can safely delete your branch and pull the changes from the main (upstream) repository.
|
||||
|
||||
1. Delete the remote branch on GitHub.
|
||||
|
||||
```
|
||||
git push origin --delete branch-name
|
||||
```
|
||||
|
||||
2. Checkout the master branch.
|
||||
|
||||
```
|
||||
git checkout master
|
||||
```
|
||||
|
||||
3. Delete the local branch.
|
||||
|
||||
```
|
||||
git branch -D branch-name
|
||||
```
|
||||
|
||||
4. Update your master branch with the latest upstream version.
|
||||
|
||||
```
|
||||
git pull upstream master
|
||||
```
|
||||
|
||||
## Skipping a Travis CI Build
|
||||
|
||||
If running a build is not required for a particular commit (in some cases like an update to README.md), add [ci skip] or [skip ci] to the git commit message. Commits that have [ci skip] or [skip ci] anywhere in the commit messages are ignored by Travis CI.
|
||||
|
||||
That's it! Thank you for your contribution!
|
||||
Reference in New Issue
Block a user