Author: AkshayCHD

The Open Event Android project consists of two components. The App Generator is a web application that is hosted on a server and generates an event Android app from a zip with JSON and binary files (examples here) or through an API. The second component we are developing in the project is a generic Android app – the output of the app generator. The Android app has a standard configuration file, that sets the details of the app (e.g. color scheme, logo of event, link to JSON app data).

The process for making a contribution in the project starts with making your account on GitHub. Secondly find the open source projects that interest you. Now as for me I started with open-event-android. Then follow these steps:

1. Go through the project’s README.md file and get information about the various aspects and technologies of the project.
2. Now fork that repo in your account.
3. Open or setup the project as per the given information present in its documentation, for example for the sample android app you have to clone the project in your local machine and open it up using Android Studios.

Now you have your version of the project now it’s time for you to use the project on your own.

While doing so you have to work like a tester of the project, so you should explore each and every bit and find out any possible anomaly in the project that you would like to work on. Once you have that you are ready to create an issue.

Following are the steps to create a new issue,

Navigate to the main repo link, you will see an issues section as follows:

• Click the new issue button and report every detail about the issue. For eg. The first issue that i worked on was Issue-1934
• Even if you don’t find any problem in the project on your own you can always work on issues created by others, you just have to let the maintainers know that you want to work on the issue by commenting in it Issue 1709.

• Now the next step is to work on that issue
• On your machine you don’t have to change the code in the development branch as it’s considered to be as a bad practice. Hence checkout as a new branch. For eg. I checked out for the above issue as ‘crashfixed’
• Make the necessary changes to that branch and test that the code is compiling and the issue is fixed followed by
• The add command is used to bring the changes to the staging area so that they are ready to be committed/saved. You can also add individual files with the command
• Next we want to save the changes that we made till now which can be done through git commit.
• Finally we would push the changes that we made to our forked repository in github.

• Now navigate to the repo and you will an option to create a Pull Request.
  Mention the Issue number and description and changes you done ,include screenshots of the fixed app.For eg.My first PR was  Pull Request 1936.

Sending the pull request is asking the maintainers of the code to add your changes to the main project which would be visible to all the contributors. But before getting merged your code may have to pass through several tests as in my case were:

-codacy/pr

-continuous-integration/travis-ci/pr

After your code passes the above tests you you would require one approved review from one of the maintainers of the project to get your code merged into the main one.

If your code is perfect in the very first attempt it would be accepted by the maintainer otherwise you would be asked to do some changes in it. You could carry out the changes on your local machine and once you are done with them you could push them to your forked repository and the changes would be amended in your pull request on its own.

Resources

• Understanding the GitHub flow,author: https://guides.github.com/introduction/flow/
• Hello World: https://guides.github.com/activities/hello-world
• 15 Minutes to learn Git: https://try.github.io/levels/1/challenges/1