How to manage Issues
This document details the processes in place for the position of “Issues Manager”, a rotating position within the QA community members.
The Issue Manager job
-Your job is to qualify issues submitted to the GitHub project. Good issues help us discover bugs and provide ideas to improve PrestaShop and the native modules. These are the three questions you must ask yourself:
+Your job is to qualify issues submitted to the GitHub project. Good issues help us discover bugs and provide ideas to improve PrestaShop and the native modules. These are the three questions you must ask yourself:
- Is the issue valid? The issue must be a bug report. We only cover the PrestaShop project (Core + native modules). Request for feature should be converted in GitHub Discussions. -
- Has all the needed information been provided? The issue must be understandable and contain the required information as provided in the issue template, complemented with any other detail needed for reproduction. -
- Can it be reproduced? An issue can’t be fixed if we can’t reproduce it. +
- Has all the needed information been provided? The issue must be understandable and contain the required information as provided in the issue template, complemented with any other detail needed for reproduction. +
- Can it be reproduced? An issue can’t be fixed if we can’t reproduce it.
Here are some tips:
-
-
- Don’t provide free support. Your job isn’t to help the reporter fix their problem, but to determine if the problem is caused by a defect in the software (or in documentation). -
- Be pragmatic about your efforts. It’s the reporter’s responsibility to provide the information needed to reproduce the problem in an understandable way. Don’t waste your energy doing guesswork or waiting for a response. -
- Don’t be a robot either. Don’t take these guidelines to the letter. If the reporter makes an effort, try to be flexible. +
- Don’t provide free support. Your job isn’t to help the reporter fix their problem, but to determine if the problem is caused by a defect in the software (or in documentation). +
- Be pragmatic about your efforts. It’s the reporter’s responsibility to provide the information needed to reproduce the problem in an understandable way. Don’t waste your energy doing guesswork or waiting for a response. +
- Don’t be a robot either. Don’t take these guidelines to the letter. If the reporter makes an effort, try to be flexible.
Issue state & labels
GitHub has only two states for issues: open and closed. We use labels to keep track of issue type, intermediate state, severity and resolution.
@@ -437,20 +429,20 @@Ad-hoc labels
develop label, try to specify the branch like 8.1.x or 9.0.xFlow overview
-Source: https://miro.com/app/board/o9J_kwzVdW0=/
+
Your routine
New issues
-The first thing to do is to deal with the new issues. This can be done by filtering out New issues. Each of these issues must be managed according to the issue processing protocol.
+The first thing to do is to deal with the new issues. This can be done by filtering out New issues. Each of these issues must be managed according to the issue processing protocol.
Issues with the NMI label
-The second step is to deal with issues labelled NMI (Need More Info) without Waiting for author label, which could have been updated by the author or any member of the community. To do this, you have to display the NMI labeled issues without Waiting for author and sort them by decreasing date of update. NMI issues are issues where crucial information is missing that only the author can provide, usually details on the reproduction steps. If the author or any member of the community has replied and provided the requested details, the issue will proceed according to the issue handling protocol.
The second step is to deal with issues labelled NMI (Need More Info) without Waiting for author label, which could have been updated by the author or any member of the community. To do this, you have to display the NMI labeled issues without Waiting for author and sort them by decreasing date of update. NMI issues are issues where crucial information is missing that only the author can provide, usually details on the reproduction steps. If the author or any member of the community has replied and provided the requested details, the issue will proceed according to the issue handling protocol.
Issues to be closed
-Finally, the third step consists in tracing the issues that have not been updated for more than 20 days, and closing them. To do this, you have to filter by increasing date and on the NMI + Waiting for authorfilter. Steps :
Finally, the third step consists in tracing the issues that have not been updated for more than 20 days, and closing them. To do this, you have to filter by increasing date and on the NMI + Waiting for authorfilter. Steps :
- Comment with the “Issue without answer” model
- Remove the
NMIlabel
@@ -459,7 +451,7 @@
Issues to be closed
End of the day
Take the time to list the issues reproduced and taken into account during the day. -Send an email to coreteam@prestashop.com, support-team@prestashop.com, qa-core@prestashop.com AND coreproduct@prestashop.com with a brief report, with a list of validated issues (aka taken into account) and duplicated issues and share the same content on Public Slack with project-members.
+Send an email to coreteam@prestashop.com, support-team@prestashop.com, qa-core@prestashop.com AND coreproduct@prestashop.com with a brief report, with a list of validated issues (aka taken into account) and duplicated issues and share the same content on Public Slack with project-members.Example:
Hello,
@@ -480,9 +472,9 @@ End of the day
First and foremost
Check that the report is really an issue!
-- Deprecated - if it’s a feature request, redirect to the appropriate template. (since April 2023)
-- If it’s a question you’re not obliged to answer it. Remember that the issues section is not a Q&A forum and that your job isn’t to provide free support. Redirect the reporter to a support plan using the “Issue is a support request” response.
-- If it’s something that you think should be described in documentation, consider pinging the developers or moving the issue to the docs project.
+- Deprecated - if it’s a feature request, redirect to the appropriate template. (since April 2023)
+- If it’s a question you’re not obliged to answer it. Remember that the issues section is not a Q&A forum and that your job isn’t to provide free support. Redirect the reporter to a support plan using the “Issue is a support request” response.
+- If it’s something that you think should be described in documentation, consider pinging the developers or moving the issue to the docs project.
- If it is a clearly incomprehensible request, close the issue by adding the
Invalid label and answer using the “Issue not completed” response.
Issue language
@@ -492,12 +484,12 @@ Issue language
Set status label to NMI (Need More Info) + Waiting for author.
Issue content
-The issue (Bug) must be complete. In particular, all mandatory fields in the template must be completed:
+The issue (Bug) must be complete. In particular, all mandatory fields in the template must be completed:
-- Describe the bug and add screenshots: full details about the bug. This part represents the “observed behavior” following user manipulations.
-- Expected behavior: the “behavior expected” by the user, to be opposed to the observed behavior detailed above. This is the nominal behavior of the application. Pay attention to the specifications.
-- Steps to Reproduce: the steps to reproduce the problem. This is the most important part and must be completed in a comprehensive manner.
-- PrestaShop version(s) where the bug happened: all affected versions
+- Describe the bug and add screenshots: full details about the bug. This part represents the “observed behavior” following user manipulations.
+- Expected behavior: the “behavior expected” by the user, to be opposed to the observed behavior detailed above. This is the nominal behavior of the application. Pay attention to the specifications.
+- Steps to Reproduce: the steps to reproduce the problem. This is the most important part and must be completed in a comprehensive manner.
+- PrestaShop version(s) where the bug happened: all affected versions
- PHP version(s) where the bug happened: PHP version
- If your bug is related to a module, specify its name and its version: the module name and its version
@@ -525,7 +517,7 @@ Duplicated issues
Close the issue.
Reproducing the issue
-We must be able to reproduce the bug in a controlled environment. You can record your attempt, use a screen recorder (like Screencastify, a Chrome extension), download it and then upload it on Github, post it in a comment so that the issue’s author can see the steps you used to reproduce their issue, either on the current branch or on develop branch, depending of what the author declared in his issue.
+We must be able to reproduce the bug in a controlled environment. You can record your attempt, use a screen recorder (like Screencastify, a Chrome extension), download it and then upload it on Github, post it in a comment so that the issue’s author can see the steps you used to reproduce their issue, either on the current branch or on develop branch, depending of what the author declared in his issue.
If the issue cannot be reproduced
We were not able to reproduce the issue like the author described, even with all possible infos provided.
@@ -534,12 +526,12 @@ If the issue cannot be reprod
- Wait 20 days, if there is no new information, you can close the issue with the message “unanswered issue”.
If the issue CAN be reproduced
-Once we have reproduced the issue with all the details given by the author, we need to check if the bug exists in the next stable PrestaShop version to be released.
-The issue is not reproduced in the next stable PrestaShop version
-That means the issue has since been corrected. So you have to find the PR that fixes the problem (it can be a migration PR, or a PR that fixes something else and fixes the problem by side effect!). We then answer the author to give him the information about the PR that fixes the problem, and tell him to update his version of PrestaShop. The issue is then closed. Add the label “Fixed” and don’t forget to add the milestone.
-The issue is reproduced in the next stable PrestaShop version
+Once we have reproduced the issue with all the details given by the author, we need to check if the bug exists in the next stable PrestaShop version to be released.
+The issue is not reproduced in the next stable PrestaShop version
+That means the issue has since been corrected. So you have to find the PR that fixes the problem (it can be a migration PR, or a PR that fixes something else and fixes the problem by side effect!). We then answer the author to give him the information about the PR that fixes the problem, and tell him to update his version of PrestaShop. The issue is then closed. Add the label “Fixed” and don’t forget to add the milestone.
+The issue is reproduced in the next stable PrestaShop version
Now we can say that the report is indeed a bug: we now add the Verified label.
-Now we have to go back up the chain to find the source of the problem. To do this, test the latest stable version of the previous minor release.
+Now we have to go back up the chain to find the source of the problem. To do this, test the latest stable version of the previous minor release.
If the issue is reproduced: the bug follows the normal course: go to the next step.
If the issue is not reproduced: It’s a regression! Test all the latest patch versions of the current minor version (e.g. 1760, 1761, 1762…) to find out in which version the issue has been introduced. If motivated, look for the PR in question. Then the issue follows the normal course: go to the next step. In addition, it has to be posted on #dev-core (Public Slack). The Project must then be labeled by selecting the label corresponding to the version in which the regression was detected.
@@ -549,7 +541,7 @@ The i
The regression of the develop branch must be placed in the Kanban of the corresponding next minor or major version.
Labelling
-This step is critical cause labelling consists on tagging the issue according to its different characteristics and it helps us find a bug when we’re looking for a duplicate. The different tags are:
+This step is critical cause labelling consists on tagging the issue according to its different characteristics and it helps us find a bug when we’re looking for a duplicate. The different tags are:
- Type (
Bug or Task),
- Severity (major, minor, …)
@@ -561,7 +553,7 @@ Labelling
- Status (NMI, Needs Specs, Ready…)
- … (non-exhaustive list)
-A list of labels and their use is available here.
+A list of labels and their use is available here.
Connecting an issue to an EPIC
When the issue is a bug that was reproduced (meaning with the Verified label), it MUST in most cases be connected to an Epic if it already exists.
@@ -570,7 +562,7 @@ Connecting an issue to an EPIC
If no Epic clearly corresponds to the issue (or in case of doubt), just add the bug issue to the 1st column of the kanban called “waiting for classification”. The product team will regularly review the issues in this kanban and create new Epics when needed.
Note that the product team must be able to understand the bug to be able to classify it in an Epic. This means that if the issue is not correctly described nor labelled, or if this is a very tech issue, it MUST NOT be added to the kanban.
Rewriting the issue
-Once all the steps have been completed, the content of the issue should be rewritten if it is unclear, or if the author has clarified in the comments. All necessary information should be available in the body of the issue! It may be necessary to rewrite the title if it is too generic (e.g. “Help! BUG!") or if it does not accurately reflect the bug.Pay special attention to the reproduction steps (“how to reproduce”)!
+Once all the steps have been completed, the content of the issue should be rewritten if it is unclear, or if the author has clarified in the comments. All necessary information should be available in the body of the issue! It may be necessary to rewrite the title if it is too generic (e.g. “Help! BUG!") or if it does not accurately reflect the bug.Pay special attention to the reproduction steps (“how to reproduce”)!
Validating the issue
If the issue is complete and unique, it’s time to validate it! For that, after having correctly labelled it, we use the “Issue validated” model. It is important to ping the team best able to answer the author’s questions: the devs, the product, the support, the qa…
Messages templates
@@ -715,7 +707,6 @@ Issue unanswered
-
diff --git a/project-organization/quality-council/processes/issue-management/index.xml b/project-organization/quality-council/processes/issue-management/index.xml
new file mode 100644
index 00000000..d7be13d6
--- /dev/null
+++ b/project-organization/quality-council/processes/issue-management/index.xml
@@ -0,0 +1,10 @@
+
+
+
+ How to manage Issues on PrestaShop Project - Open Source e-Commerce platform
+ https://www.prestashop-project.org/project-organization/quality-council/processes/issue-management/
+ Recent content in How to manage Issues on PrestaShop Project - Open Source e-Commerce platform
+ Hugo -- gohugo.io
+ en-us
+
diff --git a/project-organization/quality-council/processes/images/readme7.png b/project-organization/quality-council/processes/pr-management/img/pr-management1.png
similarity index 100%
rename from project-organization/quality-council/processes/images/readme7.png
rename to project-organization/quality-council/processes/pr-management/img/pr-management1.png
diff --git a/project-organization/quality-council/processes/images/readme16.png b/project-organization/quality-council/processes/pr-management/img/pr-management10.png
similarity index 100%
rename from project-organization/quality-council/processes/images/readme16.png
rename to project-organization/quality-council/processes/pr-management/img/pr-management10.png
diff --git a/project-organization/quality-council/processes/images/readme17.png b/project-organization/quality-council/processes/pr-management/img/pr-management11.png
similarity index 100%
rename from project-organization/quality-council/processes/images/readme17.png
rename to project-organization/quality-council/processes/pr-management/img/pr-management11.png
diff --git a/project-organization/quality-council/processes/images/readme18.png b/project-organization/quality-council/processes/pr-management/img/pr-management12.png
similarity index 100%
rename from project-organization/quality-council/processes/images/readme18.png
rename to project-organization/quality-council/processes/pr-management/img/pr-management12.png
diff --git a/project-organization/quality-council/processes/images/readme19.png b/project-organization/quality-council/processes/pr-management/img/pr-management13.png
similarity index 100%
rename from project-organization/quality-council/processes/images/readme19.png
rename to project-organization/quality-council/processes/pr-management/img/pr-management13.png
diff --git a/project-organization/quality-council/processes/images/readme20.png b/project-organization/quality-council/processes/pr-management/img/pr-management14.png
similarity index 100%
rename from project-organization/quality-council/processes/images/readme20.png
rename to project-organization/quality-council/processes/pr-management/img/pr-management14.png
diff --git a/project-organization/quality-council/processes/images/readme21.png b/project-organization/quality-council/processes/pr-management/img/pr-management15.png
similarity index 100%
rename from project-organization/quality-council/processes/images/readme21.png
rename to project-organization/quality-council/processes/pr-management/img/pr-management15.png
diff --git a/project-organization/quality-council/processes/images/readme8.png b/project-organization/quality-council/processes/pr-management/img/pr-management2.png
similarity index 100%
rename from project-organization/quality-council/processes/images/readme8.png
rename to project-organization/quality-council/processes/pr-management/img/pr-management2.png
diff --git a/project-organization/quality-council/processes/images/readme9.png b/project-organization/quality-council/processes/pr-management/img/pr-management3.png
similarity index 100%
rename from project-organization/quality-council/processes/images/readme9.png
rename to project-organization/quality-council/processes/pr-management/img/pr-management3.png
diff --git a/project-organization/quality-council/processes/images/readme10.png b/project-organization/quality-council/processes/pr-management/img/pr-management4.png
similarity index 100%
rename from project-organization/quality-council/processes/images/readme10.png
rename to project-organization/quality-council/processes/pr-management/img/pr-management4.png
diff --git a/project-organization/quality-council/processes/images/readme11.png b/project-organization/quality-council/processes/pr-management/img/pr-management5.png
similarity index 100%
rename from project-organization/quality-council/processes/images/readme11.png
rename to project-organization/quality-council/processes/pr-management/img/pr-management5.png
diff --git a/project-organization/quality-council/processes/images/readme12.png b/project-organization/quality-council/processes/pr-management/img/pr-management6.png
similarity index 100%
rename from project-organization/quality-council/processes/images/readme12.png
rename to project-organization/quality-council/processes/pr-management/img/pr-management6.png
diff --git a/project-organization/quality-council/processes/images/readme13.png b/project-organization/quality-council/processes/pr-management/img/pr-management7.png
similarity index 100%
rename from project-organization/quality-council/processes/images/readme13.png
rename to project-organization/quality-council/processes/pr-management/img/pr-management7.png
diff --git a/project-organization/quality-council/processes/images/readme14.png b/project-organization/quality-council/processes/pr-management/img/pr-management8.png
similarity index 100%
rename from project-organization/quality-council/processes/images/readme14.png
rename to project-organization/quality-council/processes/pr-management/img/pr-management8.png
diff --git a/project-organization/quality-council/processes/images/readme15.png b/project-organization/quality-council/processes/pr-management/img/pr-management9.png
similarity index 100%
rename from project-organization/quality-council/processes/images/readme15.png
rename to project-organization/quality-council/processes/pr-management/img/pr-management9.png
diff --git a/project-organization/quality-council/processes/pr-management/index.html b/project-organization/quality-council/processes/pr-management/index.html
index ba6784f3..d5e4b28e 100644
--- a/project-organization/quality-council/processes/pr-management/index.html
+++ b/project-organization/quality-council/processes/pr-management/index.html
@@ -4,8 +4,7 @@
PrestaShop Project - Open Source e-Commerce platform
-
+
@@ -27,15 +26,11 @@
-
+
-
-
-
-
-
+
+
+
@@ -228,7 +223,7 @@
-
+
@@ -313,11 +308,11 @@ How to test a PR manually
You want to take care of a PR and you don’t know how to handle it, or you’ve simply forgotten how? No problem, this github page is for you.
1. Taking information from a PR
One of the first things to do when starting a PR is to find out as much as possible about it. To do this, you’ll find this table at the start of each PR
-
+
To begin with, we have the Branch, which will be useful for preparing our shop and automated tests. So we can already set up a shop accordingly if we don’t already have a shop in this branch.
To do this, go to your terminal and execute the commands below:
ℹ️ For your information, we recommend that you put it in the Computer/var/www/html folder (this recommendation only applies to Linux users).
-
+
We can see that in violet we’ve put the “Branch “ we’re interested in and in brown the name of our file, which can be modified as we wish.
Still with this Branch, We advise you to launch the automated Tests.
ℹ️ To start the automated tests, you can go to https://github.com/PrestaShop/ga.tests.ui.pr, on the readme.md file, you will have all the information you need to run the automated tests
@@ -329,30 +324,30 @@ 2. Replicating the issue
Fixed issue or discussion: When you click on the indicated issue, you’ll have all the information you need to reproduce it.
Once on the issue, all you have to do is scroll down to find the “Steps to reproduce” section and follow the steps one by one, taking the example of our same PR:
-
+
If the issue has been validated by our testers, (⚠️ any PR that mentions an issue must have this issue validated by the QA, otherwise the PR will not be taken into account) the steps to reproduce must have been reviewed by them and are therefore easily reproducible.
ℹ️ If the issue has been validated by a Developer, the PR in question should be reviewed and tested by a Dev, unless otherwise specified.
ℹ️ If you have installed your shop in Computer/var/www/html, you will be able to use your shop from a web browser and put the link : localhost/PR_81x (this recommendation only applies to Linux users).
3 Installing the PR
Once we’ve reproduced the issue, we now need to check that the PR actually fixes the problem. To do this, we first need to install it in our shop. We’ll take out the terminal in the PR_81x folder and you’ll be able to type these commands:
-
+
ℹ️ prc here is an alias that we set up earlier like this :
prc = "!f() { git checkout $3 && git branch -D pr-$2; git fetch $1 pull/$2/head:pr-$2 && git checkout pr-$2 && git reset --hard && git clean -fd && git rebase $1/$3 && composer install; }; f"
For the color code, we always use violet for the Branch and this time we’ll use green for the PR number.
We can find this number in the title of the PR, as you can see.
-
+
All you have to do now is try to reproduce the issue again to see if the PR corrects it correctly.
If it’s all good, you can proceed to the next step of this documentation (step 4). If not, you can directly check step 5!
4. Check that the PR doesn’t create another issue
Now that you’ve checked that the PR has corrected the issue, you need to make sure that it doesn’t create another one instead. To do this, you need test axes.
To find them, go to the Files changed tab:
-
+
You’ll then have all the changes made to the PR. To do this, you’ll get this view:
-
+
Seen like this, it may seem rather difficult to see the differences and what might be impacted, so we advise you to modify the split view and save.
-
+
You now have a better view of the various modifications, and can read the whole thing.
-
+
No computer skills? But you still need to check that it’s not overflowing? There are two things you can do:
- From which file the modification was made. You can see on the screen the name of the file framed in Orange. By seeing the names, I can tell that it will be on the front by the name “FrontController”.
@@ -366,24 +361,24 @@ 5. Responding to contributors
- The PR is valid, it doesn’t create any other issue. In this case, we advise you to indicate that it works, to put a video proving it (you may think it’s the desired behavior but it’s not) and to put the link to the automated tests if you ran them.
In your comment, you’ll need to select the Approve option before submitting the review.
-
+
- The PR is not valid. In this case, indicate that it doesn’t work, put a video showing that it doesn’t work and put the link to the automated tests if you ran them (to prove that it brings issues).
If the PR corrects the issue but creates others, it is necessary to specify the steps to reproduce the issue(s) caused by the PR, so that the PR author can correct the errors more easily.
In your comment, you’ll need to select the Comment option before submitting the review. The Request changes option will force the same QA to respond to the same PR, whereas it would be preferable for someone else to test it once the changes have been made.
-
+
As you can see, in both cases, you’ll have to provide a video and a link to the automated tests to show your good faith.
ℹ️ Yes, even when the PR is valid, it’s better to offer a video. This will allow future QAs to see how we’re supposed to behave with the PR. Very useful when we’re doing test plans / release plans or when we have to go back on a PR.
Bonus - Module testing
If you come across a Module PR, the process remains the same as for a PR (in broad terms). What will change is the installation process.
To do this, start by opening your PR:
-
+
We’ve framed the PR version in Green and the “branch “** in **Purple**, represented here by **autoupgrade**.
We’re going to perform the same operations from the beginning to step 3
ℹ️ We don’t need to run the auto test, as it doesn’t work with modules.
So we’re going to run a special command in the terminal linked to our shop folder:
-
+
ℹ️ If your module includes a .json package, you need to add this command line for your module to function correctly
npm install && npm run build
ℹ️ If you want to install your module directly (if it’s not native), you can run this command in your terminal:
@@ -392,9 +387,9 @@ Bonus - Module testing
This is one of the few things that is different from a “normal” PR. We can now test the module PR and repeat the same process as in step 4.
For your information ℹ️:
If you still can’t install the module PR, you’ll probably find some hint in its readme.
-
+
Click on the branch link then scroll down and you’ll find an Installation section:
-
+
Bonus - Module testing
- diff --git a/project-organization/quality-council/processes/pr-management/index.xml b/project-organization/quality-council/processes/pr-management/index.xml new file mode 100644 index 00000000..b29c18cd --- /dev/null +++ b/project-organization/quality-council/processes/pr-management/index.xml @@ -0,0 +1,10 @@ + +1. Know the release
- Go to Prestashop Pull requests:
+
- Click on Milestones
+
- Click on the version you require (for this example, it will be 1.7.8.9)
+
- Click on Closed (these are the merged PRs for the selected version)
+
You now have the list of all the PRs merged in your release. It’s highly recommended that you check them all to find out what these PRs might affect.
2. List the test scenarios
Now that you know what your release is about, you’re going to list the different test scenarios. You’ll need support to take notes.
@@ -316,15 +308,15 @@2. List the test scenarios
- Open Prestashop project
+
- Select the various repository affected by the PRs (e.g. a change in product creation)
+
- Once you’ve identified the different scenarios that interest you, write them down (or mark them in your notepad).
+
If you’ve followed all these steps, you should now have your list of test scenarios which should be tested for this release, which you can share with your team members and developers.
All that’s left for you to do now is carry out the various tests and, at the end of the day, share with the team, made up of PMs and Developers, if we’ve encountered any issues during our work.
Happy Release.
@@ -337,7 +329,6 @@