Re: [Wikitech-l] About RESOLVED LATER
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 -- 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
Re: [Wikitech-l] About RESOLVED LATER
On Nov 13, 2012 1:05 PM, Andre Klapper aklap...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
2012/11/13 Quim Gil quim...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
* 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
On Tue, Nov 13, 2012 at 9:24 AM, Quim Gil quim...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
On 11/13/2012 10:05 AM, Nabil Maynard wrote: On Tue, Nov 13, 2012 at 9:24 AM, Quim Gil quim...@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 mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
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. -- http://hexmode.com/ Any time you have one overriding idea, and push your idea as a superior ideology, you're going to be wrong. ... The fact is, reality is complicated -- Linus Torvalds http://hexm.de/mc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
On Tue, Nov 13, 2012 at 2:01 PM, Mark A. Hershberger m...@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? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
On 11/13/2012 02:07 PM, Nathan Larson wrote: On Tue, Nov 13, 2012 at 2:01 PM, Mark A. Hershberger m...@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. -- http://hexmode.com/ Any time you have one overriding idea, and push your idea as a superior ideology, you're going to be wrong. ... The fact is, reality is complicated -- Linus Torvalds http://hexm.de/mc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
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 -- 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
Re: [Wikitech-l] About RESOLVED LATER
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 -- 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
Re: [Wikitech-l] About RESOLVED LATER
Andre Klapper aklap...@wikimedia.org wrote in message news:1352303717.10307.18.ca...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
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 -- 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
Re: [Wikitech-l] About RESOLVED LATER
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 | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
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 nadr...@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 -- 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
Re: [Wikitech-l] About RESOLVED LATER
On Nov 6, 2012, at 2:44 PM, Andre Klapper aklap...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
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-td743804.html ) +1 D On Mon, Nov 5, 2012 at 5:25 PM, Quim Gil quim...@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: http://bit.ly/YxW60z Huggle 1 MediaWiki 74 MediaWiki extensions104 Monuments database 1 mwEmbed 3 Parsoid 1 Tools 2 WikiLoves Monuments Mobile 4 Wikimedia 114 Wikimedia Labs 1 Wikimedia Mobile3 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
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. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
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 dvanli...@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-td743804.html ) +1 D On Mon, Nov 5, 2012 at 5:25 PM, Quim Gil quim...@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: http://bit.ly/YxW60z Huggle 1 MediaWiki 74 MediaWiki extensions104 Monuments database 1 mwEmbed 3 Parsoid 1 Tools 2 WikiLoves Monuments Mobile 4 Wikimedia 114 Wikimedia Labs 1 Wikimedia Mobile3 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
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-l
Re: [Wikitech-l] About RESOLVED LATER
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 zhoris...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
On Nov 5, 2012, at 11:54 PM, Platonides platoni...@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 nadr...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] About RESOLVED LATER
-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. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] On Mon, 05 Nov 2012 14:25:12 -0800, Quim Gil quim...@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: http://bit.ly/YxW60z Huggle 1 MediaWiki 74 MediaWiki extensions104 Monuments database 1 mwEmbed 3 Parsoid 1 Tools 2 WikiLoves Monuments Mobile 4 Wikimedia 114 Wikimedia Labs 1 Wikimedia Mobile3 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
Re: [Wikitech-l] About RESOLVED LATER
On Mon, Nov 5, 2012 at 5:25 PM, Quim Gil quim...@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? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
