> into a release branch and help them test the fix without checking back whichįor the QA guys, which I presume can be expected to know about our procedures, then we don't even need a comment, the whiteboard keyword is enough.įor the reporter, OK, he might not understand "target:x.y.z", the comment is more user-friendly. > mainly to report to the reporter and the QA guys when a fix will be included > Some more information about the git bugzilla script. Else, they get exactly zero notification about it, unless the patch uploader specifically adds these developers as reviewers on the gerrit side.Īctually, I kinda would appreciate an optional "automatically make me a reviewer on each gerrit change that is related to a bug where I'm CC" feature. IMHO a single notification of "a patch for this bug has been submitted to branch X" (so one comment per gerrit change and per release (not feature) branch) would be relevant to the CCed developers. > gerrit has other ways to get this information than to use bugzilla. > A developer who would be the target audience for comment notification in > for us we will miss important bugzilla mails. (.) if there are now even more mails that are totally useless Wikimedia UK's Bugzilla is at .> Please remember that some of us are put into cc for some hundred bugs by the This particular menu is useful if the issue you are reporting is time sensitive. Similarly, a new feature to an existing tool might be considered an 'enhancement' but would make the tool much more useful to a large user base, meaning it could be considered more important. A bug may be a 'blocker' for instance, but be considered to be of 'low' importance if it has a low impact. This helps the developers prioritise which bugs are most important. Once the bug has been filed, another drop down menu appears with the options: At one end of the scale a 'blocker' means that until the bug is fixed, other problems cannot be worked on, and an 'enhancement' means that the component works without the bug being addressed but that it would be an improvement. This tells the developers how your bug relates to the workflow of the component you're using. Links to a pre-filled bug report / feature request form on bugzilla.Copy the code below, and remove any unneeded section. The drop down menu gives you seven options: When creating a new bug you are asked to rate its 'severity'. In your opinion, what should be normal behaviour how do you expect the service to work?.What do you obtain (a copy/paste of the error message or a screenshot is always useful)? Specific Wikimedia Bugzilla configuration.What is the step-by-step procedure to reproduce the problem?.What is your environment (operating system, browser, email software, etc.)?.You should pay particular attention to answering the following questions clearly: On top of this, it may be useful to include information such as which web browser you were using when your ran into the problem. So for example there are options to tell the developers about the hardware you're using and the operating system. The more information you can provide about a problem, the better. For this reason, it's really important to be accurate in the way you describe your problem. Your ticket will be handled most of the time by a WMUK IT expert who might not have a clue about your context. The best kind of bug report includes a clear step-by-step account of what led up the problem. How to report a bug or request a feature? Bug reports should be created and updated in Wikimedia Phabricator instead. The Wikimedia UK developers will then try to fix the problem. Wikimedia has migrated from Bugzilla to Phabricator. You need to register an account to file a 'bug report'. If you encounter an issue on and of Wikimedia UK's website (including the wiki, the blog, QRpedia, our stats tool, and the Wiki Loves Monuments UK website) Bugzilla is the place to report it.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |