Thank you for your interest in contributing to Talawa Admin. Regardless of the size of the contribution you make, all contributions are welcome and are appreciated.
If you are new to contributing to open source, please read the Open Source Guides on How to Contribute to Open Source.
A safe environment is required for everyone to contribute. Read our Code of Conduct Guide to understand what this means. Let us know immediately if you have unacceptable experiences in this area.
No one should fear voicing their opinion. Respones must be respectful.
If you are ready to start contributing code right away, get ready!
- Join our Slack and introduce yourself. See details on how to join below in the Community section.
- This repository has its own dedicated channel.
- There are many persons on the various channels who are willing to assist you in getting started.
- Take a look at our issues (after reading our guidelines below):
- We have a list of good first issues that contain challenges with a limited scope for beginners.
- There are issues for creating tests for our code base. We need to increase reliablility. Try those issues, or create your own for files that don't already have tests. This is another good strategy for beginners.
- There are dormant issues on which nobody has worked for some time. These are another place to start
- There may also be dormant PRs on which nobody has worked for some time!
- Create an issue based on a bug you have found or a feature you would like to add. We value meaningful sugestions and will prioritize them.
Welcome aboard!
We utilize GitHub issues and pull requests to keep track of issues and contributions from the community.
Make sure you are following issue report guidelines available here before creating any new issues on Talawa Admin project.
Pull Request guidelines is best resource to follow to start working on open issues.
For Talawa Admin, we had employed the following branching strategy to simplify the development process and to ensure that only stable code is pushed to the main
branch:
develop
: For unstable code and bug fixingmain
: Where the stable production ready code lies. This is our default branch.
When multiple developers are working on issues there is bound to be a conflict of interest (not to be confused with git conflicts) among issues, PRs or even ideas. Usually these conflicts are resolved in a First Come First Serve basis however there are certain exceptions to it.
- In the cases where you feel your potential issues could be an extension or in conflict with other PRs it is important to ask the author of the PR in the slack channel or in their PRs or issues themselves why he/she did not write code for something that would require minimal effort on their part.
- Based on basic courtesy, it is good practice to let the person who created a function apply and test that function when needed.
- Last but not the least, communication is important make sure to talk to other contributors, in these cases, in slack channel or in a issue/PR thread.
- As a last resort the Admins would be responsible for deciding how to resolve this conflict.
Code contributions to Talawa come in the form of pull requests. These are done by forking the repo and making changes locally.
Make sure you have read the Documentation for Setting up the Project
The process of proposing a change to Talawa Admin can be summarized as:
-
Fork the Talawa Admin repository and branch off
develop
. -
Your newly forked repository can be cloned locally using
git clone <YOUR FORKED REPO URL>
. -
Make the Palisadoes Foundation's repo your
git upstream
for your local repo. -
Make the desired changes to the Talawa Admin project.
-
Run the app and test your changes.
-
If you've added code, then test suites must be added.
-
General:
- We need to get to 100% test coverage for the app. We periodically increase the desired test coverage for our pull requests to meet this goal.
- Pull requests that don't meet the minimum test coverage levels will not be accepted. This may mean that you will have to create tests for code you did not write. You can decide which part of the code base needs additional tests if this happens to you.
-
Testing:
-
Test using this set of commands:
npm install npm run test --watchAll=false --coverage
-
Debug tests in browser
You can see the output of failing tests in broswer by running
jest-preview
package before running your testsnpm install npm run jest-preview npm run test --watchAll=false --coverage
You don't need to re-run the
npm run jest-preview
command each time, simply run thenpm run test
command if the Jest Preview server is already running in the background, it'll automatically detect any failing tests and show the preview athttp://localhost:3336
as shown in this screenshot -
-
-
Test Code Coverage:
-
General Information
- The current code coverage of the repo is:
- You can determine the percentage test coverage of your code by running these two commands in sequence:
npm install npm run test --watchAll=false --coverage genhtml coverage/lcov.info -o coverage
- The output of the
npm run test
command will give you a tablular coverage report per file - The overall coverage rate will be visible on the penultimate line of the
genhtml
command's output. - The
genhtml
command is part of the Linuxlcov
package. Similar packages can be found for Windows and MacOS. - The currently acceptable coverage rate can be found in the GitHub Pull Request file. Search for the value below the line containing
min_coverage
.
-
Testing Individual Files
- You can test an individual file by running this command:
npm run test --watchAll=false /path/to/test/file
- You can get the test coverage report for that file by running this command. The report will list all tests in the suite. Those tests that are not run will have zero values. You will need to look for the output line relevant to your test file.
npm run test --watchAll=false --coverage /path/to/test/file
- You can test an individual file by running this command:
-
Creating your code coverage account
-
You can also see your code coverage online for your fork of the repo. This is provided by
codecov.io
-
Go to this link:
https://app.codecov.io/gh/XXXX/YYYY
where XXXX is your GitHub account username and YYYY is the name of the repository -
Login to
codecov.io
using your GitHub account, and add your repo and branches to thecodecov.io
dashboard. -
Remember to add the
Repository Upload Token
for your forked repo. This can be found underSettings
of yourcodecov.io
account. -
Use the value of this token to create a secret named CODE_COV for your forked repo.
-
You will see your code coverage reports with every push to your repo after following these steps
-
-
-
-
-
After making changes you can add them to git locally using
git add <file_name>
(to add changes only in a particular file) orgit add .
(to add all changes). -
After adding the changes you need to commit them using
git commit -m '<commit message>'
(look at the commit guidelines below for commit messages). -
Once you have successfully commited your changes, you need to push the changes to the forked repo on github using:
git push origin <branch_name>
.(Here branch name must be name of the branch you want to push the changes to.) -
Now create a pull request to the Talawa-admin repository from your forked repo. Open an issue regarding the same and link your PR to it.
-
Ensure the test suite passes, either locally or on CI once a PR has been created.
-
Review and address comments on your pull request if requested.
If you are participating in any of the various internship programs we are members of, then please read the introduction guides on our documentation website.
There are many ways to communicate with the community.
- The Palisadoes Foundation has a Slack channel where members can assist with support and clarification. Visit the Talawa GitHub repository home page for the link to join our slack channel.
- We also have a technical email list run by freelists.org. Search for "palisadoes" and join. Members on this list are also periodically added to our marketing email list that focuses on less technical aspects of our work.