I was a bit of a lazy child, specially when it came to clean up my room or do my homework. I tried to convince my mom and teachers about the paradigm of RESOLVED LATER, but they never bought it. At the end I had to clean up my room and do my homework.
Even as a child I suspected that they were actually right. If something has been postponed for later it can't be called "resolved". Now it's me who hears from time to time excuses from my kids that sound more or less like RESOLVED LATER. "Yeah, sure", I tell them, pointing to the source of pending work. :)
And now to the topic:
What about removing the LATER resolution from our Bugzilla? It feels like sweeping reports under the carpet. If a team is convinced that something won't be addressed any time soon then they can WONTFIX. If anybody feels differently then they can take the report back and fix it.
Before we could simply reopen the 311 reports filed under RESOLVED LATER:
Huggle 1 MediaWiki 74 MediaWiki extensions 104 Monuments database 1 mwEmbed 3 Parsoid 1 Tools 2 WikiLoves Monuments Mobile 4 Wikimedia 114 Wikimedia Labs 1 Wikimedia Mobile 3 Wikipedia App 3 Total 311
Looking at the total amount of open bugs, the impact is not that big. The house will be as tidy/untidy as before, but at least things wll be clearer now.
What do you think?
-- Quim
Hi,
I made the exact same argument a while back (Dropping the LATER resolution in Bugzilla http://wikimedia.7.n6.nabble.com/Dropping-the-LATER-resolution-in-Bugzilla-t... ) +1 D
On Mon, Nov 5, 2012 at 5:25 PM, Quim Gil quimgil@gmail.com wrote:
I was a bit of a lazy child, specially when it came to clean up my room or do my homework. I tried to convince my mom and teachers about the paradigm of RESOLVED LATER, but they never bought it. At the end I had to clean up my room and do my homework.
Even as a child I suspected that they were actually right. If something has been postponed for later it can't be called "resolved". Now it's me who hears from time to time excuses from my kids that sound more or less like RESOLVED LATER. "Yeah, sure", I tell them, pointing to the source of pending work. :)
And now to the topic:
What about removing the LATER resolution from our Bugzilla? It feels like sweeping reports under the carpet. If a team is convinced that something won't be addressed any time soon then they can WONTFIX. If anybody feels differently then they can take the report back and fix it.
Before we could simply reopen the 311 reports filed under RESOLVED LATER:
Huggle 1 MediaWiki 74 MediaWiki extensions 104 Monuments database 1 mwEmbed 3 Parsoid 1 Tools 2 WikiLoves Monuments Mobile 4 Wikimedia 114 Wikimedia Labs 1 Wikimedia Mobile 3 Wikipedia App 3 Total 311
Looking at the total amount of open bugs, the impact is not that big. The house will be as tidy/untidy as before, but at least things wll be clearer now.
What do you think?
-- Quim
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
Personally, I like having a "Postponed"/"Later" resolution at least available.
WONTFIX = We acknowledge this is a valid bug, but are choosing not to fix it due to time and resources necessary to fix it. We will not be revisiting this bug unless it is re-raised by others. LATER = We acknowledge this is a valid bug, and we agree that it should be fixed, but don't have time right now. We will be voluntarily revisiting this soon.
While we could arguably just dump both situations into WONTFIX, I think that would muddy the triage process pretty heavily, making it more difficult to track bugs we intend to revisit.
That said, it IS easy for LATER to become a procrastination paradise, where it gets resolved and then never thought of again. Would it be worthwhile to set up an automated notice when a LATER bug ages past a certain date (say, a month without being touched), instead of axing the resolution?
Thanks, Nabil
On Mon, Nov 5, 2012 at 2:29 PM, Diederik van Liere dvanliere@wikimedia.orgwrote:
Hi,
I made the exact same argument a while back (Dropping the LATER resolution in Bugzilla
http://wikimedia.7.n6.nabble.com/Dropping-the-LATER-resolution-in-Bugzilla-t... ) +1 D
On Mon, Nov 5, 2012 at 5:25 PM, Quim Gil quimgil@gmail.com wrote:
I was a bit of a lazy child, specially when it came to clean up my room
or
do my homework. I tried to convince my mom and teachers about the
paradigm
of RESOLVED LATER, but they never bought it. At the end I had to clean up my room and do my homework.
Even as a child I suspected that they were actually right. If something has been postponed for later it can't be called "resolved". Now it's me
who
hears from time to time excuses from my kids that sound more or less like RESOLVED LATER. "Yeah, sure", I tell them, pointing to the source of pending work. :)
And now to the topic:
What about removing the LATER resolution from our Bugzilla? It feels like sweeping reports under the carpet. If a team is convinced that something won't be addressed any time soon then they can WONTFIX. If anybody feels differently then they can take the report back and fix it.
Before we could simply reopen the 311 reports filed under RESOLVED LATER:
Huggle 1 MediaWiki 74 MediaWiki extensions 104 Monuments database 1 mwEmbed 3 Parsoid 1 Tools 2 WikiLoves Monuments Mobile 4 Wikimedia 114 Wikimedia Labs 1 Wikimedia Mobile 3 Wikipedia App 3 Total 311
Looking at the total amount of open bugs, the impact is not that big. The house will be as tidy/untidy as before, but at least things wll be
clearer
now.
What do you think?
-- Quim
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-l<
https://lists.wikimedia.org/mailman/listinfo/wikitech-l%3E
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 05/11/2012 16:02, Nabil Maynard wrote:
Personally, I like having a "Postponed"/"Later" resolution at least available.
WONTFIX = We acknowledge this is a valid bug, but are choosing not to fix it due to time and resources necessary to fix it. We will not be revisiting this bug unless it is re-raised by others. LATER = We acknowledge this is a valid bug, and we agree that it should be fixed, but don't have time right now. We will be voluntarily revisiting this soon.
If that's what later means, then why mark it at all? These are big projects, and are others or even newcomers later who may indeed have the time, so why remove that option from everyone?
Open bugs don't hurt anything, do they?
I suppose that depends on the particular project. From the sounds of it, the discussion is about removing LATER as a resolution option across the entire database, including some projects that do have specific people driving development (some extensions, for instance). There is also absolutely no reason newcomers or others couldn't do a search for postponed bugs, and use that as a jumping off point for contributing to a project. You aren't removing that option to contribute from anyone.
Yes, you could arguably just keep it open, but that gets into the same issue as stuffing everything into WONTFIX, where it is making it more difficult to track which bugs are fresh, and which are extant bugs you'd like to get to, but either don't have cycles for or are otherwise blocked. The point of having the additional granularity is to make it easier to keep the database organized.
Nabil
On Mon, Nov 5, 2012 at 3:10 PM, Isarra Yos zhorishna@gmail.com wrote:
On 05/11/2012 16:02, Nabil Maynard wrote:
Personally, I like having a "Postponed"/"Later" resolution at least available.
WONTFIX = We acknowledge this is a valid bug, but are choosing not to fix it due to time and resources necessary to fix it. We will not be revisiting this bug unless it is re-raised by others. LATER = We acknowledge this is a valid bug, and we agree that it should be fixed, but don't have time right now. We will be voluntarily revisiting this soon.
If that's what later means, then why mark it at all? These are big projects, and are others or even newcomers later who may indeed have the time, so why remove that option from everyone?
Open bugs don't hurt anything, do they?
-- -— Isarra
______________________________**_________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 11/05/2012 03:02 PM, Nabil Maynard wrote:
WONTFIX = We acknowledge this is a valid bug, but are choosing not to fix it due to time and resources necessary to fix it. We will not be revisiting this bug unless it is re-raised by others. LATER = We acknowledge this is a valid bug, and we agree that it should be fixed, but don't have time right now. We will be voluntarily revisiting this soon.
Actually no.
WONTFIX = Your feature proposed doesn't fit in our plans for this project, or the minor bug you get occasionally implies to rewrite everything (etc) therefore we choose not to fix it - neither we expect anybody else to address it unless they fork the whole project. If you believe we are wrong convince us and we might reopen.
If a report is valid but there are no resources to address it then it should be left open as NEW with LOW priority, making it easy to be searched.
NEW-LOW and RESOLVED-WONTFIX are clear answers that throw the ball back to the reporter or anybody else interested in the report. RESOLVED-LATER is confusing and leaves certain expectation, with a higher possibility of losing the ball between the cracks.
The comments about LATER make theoretical sense, but the practice of bug trackers leaves little room for doubt: the reports that are not open are perceived as closed for good. They disappear from lists and reports, and are forgotten soon.
-- Quim
How many of them depend on action from somebody else? (eg. upstream fixing its tool)
Of course, if we are waiting for upstream, it should list the upstream bug id, have upstream keyword, someone actually noticing when it's fixed, etc. but those are form issues, not the status. (and yes, 'resolved' is a misnomer)
Bug tracking software should be able to communicate between themselves to automatically open and close its bugs when they have dependencies.
On Nov 5, 2012, at 11:54 PM, Platonides Platonides@gmail.com wrote:
How many of them depend on action from somebody else? (eg. upstream fixing its tool)
Of course, if we are waiting for upstream, it should list the upstream bug id, have upstream keyword, someone actually noticing when it's fixed, etc. but those are form issues, not the status. (and yes, 'resolved' is a misnomer)
On Nov 6, 2012, at 12:02 AM, Nabil Maynard nadreck@gmail.com wrote:
LATER = We acknowledge this is a valid bug, and we agree that it should be fixed, but don't have time right now. We will be voluntarily revisiting this soon.
While we could arguably just dump both situations into WONTFIX, I think that would muddy the triage process pretty heavily, making it more difficult to track bugs we intend to revisit.
That said, it IS easy for LATER to become a procrastination paradise, where it gets resolved and then never thought of again. Would it be worthwhile to set up an automated notice when a LATER bug ages past a certain date (say, a month without being touched), instead of axing the resolution?
I agree we should drop this status.
We have the following indications that should be used instead:
* blockers / dependencies * status ASSIGNED * keyword upstream * priority low or lowest * severity minor * or, resolved-wontfix if that is the case.
Using LATER in any of these cases only causes the bug to be lost end omitted from searches and lists.
I don't think it depends on the project, it depends on the user making the query not knowing how to utilise the above factors.
If one wants to generate a list to work off of that doesn't contain any of these, exclude them in the search parameters as desired. Don't stamp LATER on the bugs to make it fit the lazy search that only omits "RESOLVED/**".
@AndreKlapper: What do you think?
-- Krinkle
Hi,
[See my comments inline]
Quim: Thanks for the wonderful analogy and bringing this up again.
The question boils down to:
How and why do people use RESOLVED LATER?
The same topic was discussed one year ago in http://lists.wikimedia.org/pipermail/wikitech-l/2011-November/056583.html and other projects had similar problems with RESOLVED LATER, e.g. see http://www.eclipsezone.com/eclipse/forums/t83053.html Upstream Bugzilla developers removed RESOLVED LATER for Bugzilla ⪖3.0: https://bugzilla.mozilla.org/show_bug.cgi?id=13534
On Nov 6, 2012, at 12:02 AM, Nabil Maynard nadreck@gmail.com wrote:
That said, it IS easy for LATER to become a procrastination paradise, where it gets resolved and then never thought of again. Would it be worthwhile to set up an automated notice when a LATER bug ages past a certain date (say, a month without being touched), instead of axing the resolution?
One posting from last year's thread also stated "Currently the LATER acts as a blackhole and there is no structured process to re-evaluate these kind of bugs." (If importing from the compressed archives wasn't broken I could even tell you who wrote that.)
On Tue, 2012-11-06 at 02:24 +0100, Krinkle wrote:
We have the following indications that should be used instead:
- blockers / dependencies
- status ASSIGNED
- keyword upstream
- priority low or lowest
- severity minor
- or, resolved-wontfix if that is the case.
Using LATER in any of these cases only causes the bug to be lost end omitted from searches and lists.
I don't think it depends on the project, it depends on the user making the query not knowing how to utilise the above factors.
If one wants to generate a list to work off of that doesn't contain any of these, exclude them in the search parameters as desired. Don't stamp LATER on the bugs to make it fit the lazy search that only omits "RESOLVED/**".
+1.
My interpretation of potential meanings from the top of my head: * Meaning of "priority = lowest" (and potentially "Target Milestone = Mysterious Future" if TMs were really used). Using this obviously would not remove the report from being listed in the search results for open tickets, and I assume that people are lazy to run more complicated searches in Bugzilla to exclude those. Or rephrase this to "Bugzilla makes it hard to run useful queries" if you think that you're not lazy, but that it's the technology's fault. * Meaning of "RESOLVED WONTFIX". But as that sounds harsh the original reporter could disagree and start discussing, and discussing takes time the WONTFIXer would like to avoid spending. Social problem that requires explaining well why WONTFIX was set. * Meaning of "depends on UPSTREAM". We won't fix it ourselves but wait for an upstream fix. We won't backport the upstream fix but wait until we upgrade servers to an entire new Ubuntu version which provides a newer package that includes the fix. The Mer project uses "RESOLVED WAITING_FOR_UPSTREAM" for this.
If I miss meanings, please provide them.
Currently I'm in favor of killing RESOLVED LATER (which requires retriaging these tickets) and introducing a RESOLVED WAITING_FOR_UPSTREAM status for the latter case.
andre
On Nov 6, 2012, at 2:44 PM, Andre Klapper aklapper@wikimedia.org wrote:
On Tue, 2012-11-06 at 02:24 +0100, Krinkle wrote:
We have the following indications that should be used instead:
- blockers / dependencies
- status ASSIGNED
- keyword upstream
- priority low or lowest
- severity minor
- or, resolved-wontfix if that is the case.
Using LATER in any of these cases only causes the bug to be lost end omitted from searches and lists.
I don't think it depends on the project, it depends on the user making the query not knowing how to utilise the above factors.
If one wants to generate a list to work off of that doesn't contain any of these, exclude them in the search parameters as desired. Don't stamp LATER on the bugs to make it fit the lazy search that only omits "RESOLVED/**".
[..] * Meaning of "depends on UPSTREAM". We won't fix it ourselves but wait for an upstream fix. We won't backport the upstream fix but wait until we upgrade servers to an entire new Ubuntu version which provides a newer package that includes the fix. The Mer project uses "RESOLVED WAITING_FOR_UPSTREAM" for this.
If I miss meanings, please provide them.
Currently I'm in favor of killing RESOLVED LATER (which requires retriaging these tickets) and introducing a RESOLVED WAITING_FOR_UPSTREAM status for the latter case.
andre
I'm not sure the extra resolved status makes sense. The issue is clearly not resolved and upstream is already indicated with the upstream keyword.
As for making complex queries, this may take a minute the first time, but doesn't have to be repeated.
The VisualEditor team, for example, has about half a dozen useful queries that are "shared" within the team (any bz user can enable it in their preferences) that the product manager maintains for us. We just click them when we need to know what's up.
And then there is the product-independent query that is useful for developers: "Bugs assigned to me" (that is, with status=ASSIGNED, not just any bug that was by default assigned to you).
Also, why would want to exclude "Waiting for upstream" bugs from triage lists? During a weekly triage I suppose it makes sense to evaluate these as well. Just like one would check up on a patch or the contributor, one would check up on the upstream ticket and maybe poke someone there.
-- Krinkle
-1
There is an important difference between WONTFIX and LATER.
WONTFIX is something rejected because it's a bad idea, etc... LATER is something rejected because there are technical reasons we can't do it any time soon now. But in the future after some major even it's possible that we can finally fix it.
The key point being that we don't ditch it because we won't fix it, but rather because we can't yet.
And that is very important.
If something is RESOLVED LATER. Then periodically and after major things happen we can look back through RESOLVED LATER and finally pick out old bugs we can fix. Something beautiful since these can be major improvements to MediaWiki.
But if we instead resolve things we might be able to fix in the future as WONTFIX and dilute them right along side bugs that should NEVER be implemented... then we can no longer look back and find old bugs we can finally fix.
If you want to get rid of RESOLVED LATER. You should first compile a full history of bugs and make a list of all bugs that were once marked RESOLVED LATER and then were given a new resolution.
On 11/05/2012 07:13 PM, Daniel Friesen wrote:
The key point being that we don't ditch it because we won't fix it, but rather because we can't yet.
Any reason why this couldn't be NEW - LOWEST priority? As soon as you can then you can raise the priority.
If you want to get rid of RESOLVED LATER. You should first compile a full history of bugs and make a list of all bugs that were once marked RESOLVED LATER and then were given a new resolution.
-- Quim
On Mon, 05 Nov 2012 22:16:20 -0800, Quim Gil quimgil@gmail.com wrote:
On 11/05/2012 07:13 PM, Daniel Friesen wrote:
The key point being that we don't ditch it because we won't fix it, but rather because we can't yet.
Any reason why this couldn't be NEW - LOWEST priority? As soon as you can then you can raise the priority.
If you want to get rid of RESOLVED LATER. You should first compile a full history of bugs and make a list of all bugs that were once marked RESOLVED LATER and then were given a new resolution.
-- Quim
Things with the lowest priority should be things that "could" be fixed. But we've got no reason to implement ourselves. LATER should be things that for some technical reason outside our control, right-now we cannot fix. They shouldn't be blended into "Lowest" list of bugs that are possible but waiting for some enterprising 3rd party to take on.
eg: Add HTML 5 semantic elements 'details' and 'summary' to Sanitizer whitelist [https://bugzilla.wikimedia.org/show_bug.cgi?id=29118] RESOLVED LATER due to lack of browser support, waiting the months/years till it is better adopted by browsers and we can defrost the bug.
-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Andre, I don't think we need a new resolution WAITING_FOR_UPSTREAM. The main point is: the moment they are RESOLVED they don't appear in most searches. Using the "upstream" keyword is more than enough.
On 11/05/2012 10:56 PM, Daniel Friesen wrote:
Things with the lowest priority should be things that "could" be fixed. But we've got no reason to implement ourselves. LATER should be things that for some technical reason outside our control, right-now we cannot fix. They shouldn't be blended into "Lowest" list of bugs that are possible but waiting for some enterprising 3rd party to take on.
The priority is a minor detail. If "lowest" is so bad we could have "Waiting" or "unprioritized" or whatever else.
eg: Add HTML 5 semantic elements 'details' and 'summary' to Sanitizer whitelist [https://bugzilla.wikimedia.org/show_bug.cgi?id=29118] RESOLVED LATER due to lack of browser support, waiting the months/years till it is better adopted by browsers and we can defrost the bug.
That one could perfectly sit as NEW with an "upstream" keyword and the priority you desire.
When doing a simple search on the keyboard "upstream" Bugzilla shows the ones that are open (95):
https://bugzilla.wikimedia.org/buglist.cgi?keywords=upstream
There are 20 more reports RESOLVED LATER waiting for upstream, but these only appear when doing a specific advanced search:
https://bugzilla.wikimedia.org/buglist.cgi?keywords=upstream%2C%20&query...
-- Quim
On Tue, 2012-11-06 at 14:10 -0800, Quim Gil wrote:
Andre, I don't think we need a new resolution WAITING_FOR_UPSTREAM.
After reading Krinkle's and your email I agree that there is no urgent need for it. This could still be reevaluated in the future.
andre
"Andre Klapper" aklapper@wikimedia.org wrote in message news:1352303717.10307.18.camel@embrace.foo...
On Tue, 2012-11-06 at 14:10 -0800, Quim Gil wrote:
Andre, I don't think we need a new resolution WAITING_FOR_UPSTREAM.
After reading Krinkle's and your email I agree that there is no urgent need for it. This could still be reevaluated in the future.
Please therefore mark the suggestion as RESOLVED LATER
:-)
- HappyDog
Hi Daniel,
On Mon, 2012-11-05 at 22:56 -0800, Daniel Friesen wrote:
Things with the lowest priority should be things that "could" be fixed. But we've got no reason to implement ourselves. LATER should be things that for some technical reason outside our control, right-now we cannot fix.
Is "outside of our control" that different from "we cannot or will not fix it for other reasons, like missing manpower / different priorities etc" that it deserves marking such reports differently? What's the gain? (Not sure myself, hence throwing this question into the room.)
If we cannot fix a report for a reason beyond our control it's again a status like "waiting for upstream" (or "waiting for something to happen outside of the WM universe"), isn't it?
eg: Add HTML 5 semantic elements 'details' and 'summary' to Sanitizer whitelist [https://bugzilla.wikimedia.org/show_bug.cgi?id=29118] RESOLVED LATER due to lack of browser support, waiting the months/years till it is better adopted by browsers and we can defrost the bug.
Sounds like a candidate for lowest priority if you don't want to spend time on it in the next two years but maybe afterwards. It's not an issue that got "resolved" for good (that's my interpretation of a "resolution" - it should be for good, theoretically). Of course Bugzilla allows you to revert the RESOLVED status, but to me that's when a mistake has been made (commit didn't fix the issue, etc). On the contrary, "RESOLVED LATER" sounds like a "resolution" that ALWAYS has to get reverted... "later".
andre
On Mon, Nov 5, 2012 at 5:25 PM, Quim Gil quimgil@gmail.com wrote:
What about removing the LATER resolution from our Bugzilla? It feels like sweeping reports under the carpet. If a team is convinced that something won't be addressed any time soon then they can WONTFIX. If anybody feels differently then they can take the report back and fix it.
Before we could simply reopen the 311 reports filed under RESOLVED LATER:
Should we create a new status, e.g. BLOCKED or LATER (rather than RESOLVED LATER) for these?
On Mon, 2012-11-05 at 14:25 -0800, Quim Gil wrote:
What about removing the LATER resolution from our Bugzilla?
Picking this up again.
Reading the postings again I mostly see support for dropping RESOLVED LATER. Daniel uses this for tickets whose solution is out of our control. As mentioned they could be marked via using the "upstream" keyword (preferably with an upstream tracking URL in the "See Also" field) in combination with the "upstream" keyword.
Assuming agreement that RESOLVED LATER is deprecated and lowest priority is used, * some community members need to adjust their Bugzilla queries to exclude such tickets. * we need to actively discourage the use of RESOLVED LATER for tickets recently marked as such, and point to this thread. Help welcome. * we need to go through all RESOLVED LATER tickets, reopen them by setting appropriate values (lowest priority, upstream), and explain why (pointing to this thread). Help welcome.
Once no RESOLVED LATER tickets remain, I can remove the resolution.
Silence means approval.
andre
On Nov 13, 2012 1:05 PM, "Andre Klapper" aklapper@wikimedia.org wrote:
On Mon, 2012-11-05 at 14:25 -0800, Quim Gil wrote:
What about removing the LATER resolution from our Bugzilla?
Picking this up again.
Reading the postings again I mostly see support for dropping RESOLVED LATER. Daniel uses this for tickets whose solution is out of our control. As mentioned they could be marked via using the "upstream" keyword (preferably with an upstream tracking URL in the "See Also" field) in combination with the "upstream" keyword.
Assuming agreement that RESOLVED LATER is deprecated and lowest priority is used, * some community members need to adjust their Bugzilla queries to exclude such tickets. * we need to actively discourage the use of RESOLVED LATER for tickets recently marked as such, and point to this thread. Help welcome. * we need to go through all RESOLVED LATER tickets, reopen them by setting appropriate values (lowest priority, upstream), and explain why (pointing to this thread). Help welcome.
Once no RESOLVED LATER tickets remain, I can remove the resolution.
Silence means approval.
No it doesn't.
andre
Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 11/13/2012 11:54 AM, Martijn Hoekstra wrote:
Once no RESOLVED LATER tickets remain, I can remove the resolution.
Silence means approval.
No it doesn't.
The above exchange really confuses me.
I'm not sure what else silence could mean when someone explicitly tells you (as Andre has) "If no one voices any objections, I'm going to do this." Could you clarify?
And, if you think silence doesn't mean approval, wouldn't you be better served by speaking up an voicing your concerns? It certainly seems like you'd be better served by clearly stating your objection than by a terse reply such as you've given.
Mark.
On Tue, Nov 13, 2012 at 2:01 PM, Mark A. Hershberger mah@everybody.orgwrote:
On 11/13/2012 11:54 AM, Martijn Hoekstra wrote:
Once no RESOLVED LATER tickets remain, I can remove the resolution.
Silence means approval.
No it doesn't.
The above exchange really confuses me.
I'm not sure what else silence could mean when someone explicitly tells you (as Andre has) "If no one voices any objections, I'm going to do this." Could you clarify?
And, if you think silence doesn't mean approval, wouldn't you be better served by speaking up an voicing your concerns? It certainly seems like you'd be better served by clearly stating your objection than by a terse reply such as you've given.
Mark.
Perhaps it should've been "silence means acquiescence"?
On 11/13/2012 02:07 PM, Nathan Larson wrote:
On Tue, Nov 13, 2012 at 2:01 PM, Mark A. Hershberger mah@everybody.orgwrote:
On 11/13/2012 11:54 AM, Martijn Hoekstra wrote:
Silence means approval.
No it doesn't.
The above exchange really confuses me.
Perhaps it should've been "silence means acquiescence"?
Good point. It still has some negative connotations, though. Stick to single syllable words: "If no one says anything, this is what I will do."
On Tue, 2012-11-13 at 14:16 -0500, Mark A. Hershberger wrote:
Good point. It still has some negative connotations, though. Stick to single syllable words: "If no one says anything, this is what I will do."
That's definitely a better wording of what I wanted to express, thanks.
andre
On Tue, 2012-11-13 at 14:16 -0500, Mark A. Hershberger wrote:
Good point. It still has some negative connotations, though. Stick to single syllable words: "If no one says anything, this is what I will do."
That's definitely a better wording for what I wanted to express. Thanks.
andre
Hi, trying to find the simplest path:
On 11/13/2012 04:04 AM, Andre Klapper wrote:
Assuming agreement that RESOLVED LATER is deprecated and lowest priority is used, * some community members need to adjust their Bugzilla queries to exclude such tickets.
They will find out those queries return no results anymore. No harm done.
* we need to go through all RESOLVED LATER tickets, reopen them by setting appropriate values (lowest priority, upstream), and explain why (pointing to this thread). Help welcome.
Since free time is a luxury, what about simply a bulk change TO NEW / LOWEST. I know it's not a perfect solution, but is a big improvement done fast. Then active teams and contributors (many of them receiving notifications for the changes) will fine tune each one of them. Or not, but this would mean that such reports would have been ignored anyway in your eventual call for volunteers.
What I mean is that by doing a bulk change there is a potential for saving time, and no potential for wasting more time.
* we need to actively discourage the use of RESOLVED LATER for tickets recently marked as such, and point to this thread. Help welcome.
This can be easily implemented after the bulk change, by removing LATER altogether.
Once no RESOLVED LATER tickets remain, I can remove the resolution.
Another benefit of the bulk change is that quick transitions are better than long transitions.
One alternative is to give people a week to change manually the resolution of LATER report, and then do the bulk change with the remaining ones.
-- Quim
2012/11/13 Quim Gil quimgil@gmail.com:
* we need to go through all RESOLVED LATER tickets, reopen them by setting appropriate values (lowest priority, upstream), and explain why (pointing to this thread). Help welcome.Since free time is a luxury, what about simply a bulk change TO NEW / LOWEST. I know it's not a perfect solution, but is a big improvement done fast. Then active teams and contributors (many of them receiving notifications for the changes) will fine tune each one of them. Or not, but this would mean that such reports would have been ignored anyway in your eventual call for volunteers.
I think somebody (or possibly a few somebodies with knowledge of different parts of the code) should at least quickly scan these lists, since some of the things marked as LATER might have been fixed in the meantime (and nobody found the bug to close, since it was RESOLVED) or have been made irrelevant (such as https://bugzilla.wikimedia.org/show_bug.cgi?id=34329 which I found skimming the list a few days ago).
-- Matma Rex
* we need to go through all RESOLVED LATER tickets, reopen them by setting appropriate values (lowest priority, upstream), and explain why (pointing to this thread). Help welcome.Since free time is a luxury, what about simply a bulk change TO NEW / LOWEST. I know it's not a perfect solution, but is a big improvement done fast. Then active teams and contributors (many of them receiving notifications for the changes) will fine tune each one of them. Or not, but this would mean that such reports would have been ignored anyway in your eventual call for volunteers.
I think somebody (or possibly a few somebodies with knowledge of different parts of the code) should at least quickly scan these lists, since some of the things marked as LATER might have been fixed in the meantime (and nobody found the bug to close, since it was RESOLVED) or have been made irrelevant (such as https://bugzilla.wikimedia.org/show_bug.cgi?id=34329 which I found skimming the list a few days ago).
A week provides ample time to do that. Although, I'm sure if there are disagreements on that length of time, another could easily be decided upon.
Thank you, Derric Atzrott
On Tue, Nov 13, 2012 at 9:24 AM, Quim Gil quimgil@gmail.com wrote:
On 11/13/2012 04:04 AM, Andre Klapper wrote:
Assuming agreement that RESOLVED LATER is deprecated and lowest priority is used, * some community members need to adjust their Bugzilla queries to exclude such tickets.
They will find out those queries return no results anymore. No harm done.
I apparently read this entirely differently than you: as written, that sounds more like "community members need to adjust their Bugzilla queries to exclude LOWEST/UPSTREAM". At which point, why are we removing RESOLVED/LATER again? You're moving things from one bucket to another bucket, but doesn't actually raise visibility or alter how we think about the bugs.
Nabil
On 11/13/2012 10:05 AM, Nabil Maynard wrote:
On Tue, Nov 13, 2012 at 9:24 AM, Quim Gil quimgil@gmail.com wrote:
On 11/13/2012 04:04 AM, Andre Klapper wrote:
Assuming agreement that RESOLVED LATER is deprecated and lowest priority is used, * some community members need to adjust their Bugzilla queries to exclude such tickets.
They will find out those queries return no results anymore. No harm done.
I apparently read this entirely differently than you: as written, that sounds more like "community members need to adjust their Bugzilla queries to exclude LOWEST/UPSTREAM". At which point, why are we removing RESOLVED/LATER again?
As explained: for clarity and for all those not doing specific queries to RESOLVED reports. NEW reports appear in search result s by default, RESOLVED reports not.
You're moving things from one bucket to another bucket, but doesn't actually raise visibility or alter how we think about the bugs.
As you see, it does raise visibility. Specially among newcomers, externals and casual contributors, who are good candidates to actually help pushing those bugs.
-- Quim
wikitech-l@lists.wikimedia.org