Payment SDK Android Development process

Planning

Since this project will be developed by MobiLab employees and when they have time it is important to streamline the planning and tracking process and make it as easy as possible to maintin in small chunks of time somebody is working on it. For that purpose we define the following rules.

Basics

Everything artifact in the planning process is represented by a GitHub issue.

Issue format

Issues can be reported by community in case of bug reports or feature requests, or come from inside the organization. In case issue is a bug report it should follow this format:

• Clear and concise name
• Description of the problem
• Steps to reproduce
• Any logs should be included as gists
• Issue must be have a bug label applied to it

If the issue is a feature request it should follow this format:

• Clear and concise name
• Description of the request
• Reasoning behind the request
• Labels that will bring attention of the correct contributors (e.g. Documentation-WIKI if the issue is regarding documentation)

If the issue is a user story it should have the following format:

• Clear and concise name (Add credit card support for ...)
• User perspective (e.g As a user/developer/contributor I ...)
• Any additional and relevant information (e.g. This PSP doesn't support PayPal...)
• Story label applied to it
• Relevant labels applied to it

Adding stories/issues/tasks to the project board

Once the story/issue is added to the board, it is considered planned, issues on the board are sorted by highest priority first.

PO is responsible for adding new stories/issues to the project board (either from feature requests from the community, or other sources). To do this you must follow these steps:

1. Make sure the story has a good description as well as user perspective
2. Make sure that the story has a well defined acceptance criteria
3. Add appropriate labels

Since some community contributed issues/requests might not follow the defined format it the responsibility of PO to modify it so it does.

Implementing a story or an issue

When you are starting to work on a story/issue you should assign it to yourself and move it to In Progress column. Once you are done coding create a pull request mentioning the issue/story id.

Issue/Story is considered implemented when following criteria is met:

• Implemented functionality
• Implemented tests
• Code is documented
• If necessary additional documentation is updated on the wiki/README
• Pull request has been reviewed

Once all criteria have been met, move the story/issue to Implemented column.

Testing a story or an issue

When you are ready to start testing, move the story/issue to Testing column. The story/issue is considered tested when:

• All automated tests pass
• A sanity test on the rest of the SDK is performed
• Manual testing of the feature implemented is done
• A short overview of the way the story/issue was tested is written as a comment in the issue

Once all criteria have been met the, mve the issue to Tested column

#Accepting the issue PO should confirm that the implemented and tested issue/story works as expected and defined in the description. Once that is confirmed the issue can be moved to Done column