Notice: You are browsing the documentation for PrestaShop 8, which is currently in development.You might want to read the documentation for the current version, PrestaShop 1.7.
GitHub is the main tool used by maintainers to manage the PrestaShop project.
On GitHub, there are mainly three teams working together on the project.
A maintainer will naturally belong to the Developers team but can also assist and work with the Product Team and QA Team.
Currently, there are 4 different types of Issues submitted by users on GitHub.
When a user submits a Feature Request, it can be either a Product feature request (example: add a new Back office page) or a Technical feature request (example: support PostgreSQL).
Product feature requests are labelled “Waiting for PM” while Technical feature request are labelled “Waiting for dev”.
The team in charge will then analyse the request and either reject it or accept it. Rejected feature requests are closed while accepted feature requests are added to the roadmap and labelled. Labels will help triaging the backlog.
When a user submits a bug report, the QA team will analyse it and attempt to reproduce it. If it can be reproduced and is confirmed to be an issue, it will be labelled and added to the roadmap.
If it cannot be reproduced, QA team will attempt to explore the issue with the contributor to isolate the very settings responsible for the buggy behavior.
If the user does not answer for 30 days or after multiple attempts, it cannot be reproduced on our side, the issue is closed.
If the bug report is confirmed, one of the key elements to evaluate is whether it is a regression. A regression is a bug that cannot be observed in the previous PrestaShop version, it means the software quality level has decreased instead of increasing. Regressions are usually milestoned to be fixed in the next patch version.
The work of analyzing and testing all submitted bug reports is a very complex one, because there might be a very diverse range of reports. Moreover quite a huge number of them are actually not related to the software but to how the shop is being used: the server configuration, the shop configuration, the installed modules and the installed theme might introduce buggy behaviors that the user mistakenly believes come from the software.
This is why so much Issues cannot be reproducted on our side, but to find it out multiple explorations and attempts are necessary.
We sometimes receive support requests on GitHub, ranging from questions about the software to “please help me to do X in my shop” requests. GitHub is for the software development so we usually redirect users to other channels using the Support template.
There are some Issues which do not fit in the previous categories, such as releases Issues. They serve a specific purpose.
When a contributor submits a Pull Request, it goes through multiple stages.
Maintainers must first validate that the Pull Request is eligible to review (the template is filled, the license headers are correct, the target branch is the right one …).
If there is an issue with the Pull Request and it is not eligible, maintainers kindly ask the contributor to fix it.
If the Pull Request is eligible, maintainers can evaluate if the changes brought by the Pull Request are desirables.
If one “Waiting for …” label has been applied, the team in charge will process the Pull Request and then add a “… approved” label. For example if Product team validates the new behavior implemented in a Pull Request, they will remove the “Waiting for PM” label and add the “PM approved” label instead.
There are some automated bots running on GitHub that will help maintainers to label the Pull Requests. For example Prestonbot is able to extract the new wordings and add the “Waiting for wording” label. You can read more about them here.
If the Pull Request is validated and there are no more “Waiting for …” labels, then it awaits a code review. Maintainers provide this code review.
A maintainer can choose to
When the Pull Request has been approved (it needs two approvals on the Core repository), the Pull Request must be tested. It is labelled “Waiting for QA”.
On regular Pull Requests, the QA team is in charge of testing the Pull Request. They will use the “How to test” part of the Pull Request description to validate the behavior implemented, and also run some more tests to validate there are no regressions.
Some Pull Requests however cannot be tested by QA team, the Developers team might validate them.
If the Pull Request is tested successfully, the label “QA approved” is applied. Else, the author is notified about the Issues found by the tests.
Pull Requests that have been validated by QA can be merged. They must also be milestoned, and if they fix an issue, the issue must be labelled, milestoned, and closed.