Hi,
I sometimes see WMF developers and product managers marking tasks as "Declined" with comments such as these: * "No resources for it in (team name)" * "We won't have the resources to work on this anytime soon." * "I do not plan to work on this any time soon."
Can we perhaps agree that the "Declined" status shouldn't be used like this?
"Declined" should be valid when: * The component is no longer maintained (this is often done as mass-declining). * A product manager, a developer, or any other sensible stakeholder thinks that doing the task as proposed is a bad idea. There are also variants of this: * The person who filed the tasks misunderstood what the software component is supposed to do and had wrong expectations. * The person who filed the tasks identified a real problem, but another task proposes a better solution.
It's quite possible that some people will disagree with the decision to mark a particular task as "Declined", but the reasons above are legitimate explanations.
However, if the task suggests a valid idea, but the reason for declining is that a team or a person doesn't plan to work on it because of lack of resources or different near-term priorities, it's quite problematic to mark it as Declined.
It's possible to reopen tasks, of course, but nevertheless "Declined" gives a somewhat permanent feeling, and may cause good ideas to get lost.
So can we perhaps decide that such tasks should just remain Open? Maybe with a Lowest priority, maybe in something like a "Freezer" or "Long term" or "Volunteer needed" column on a project workboard, but nevertheless Open?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
Pe marți, 2 octombrie 2018, Amir E. Aharoni amir.aharoni@mail.huji.ac.il a scris:
Hi,
I sometimes see WMF developers and product managers marking tasks as "Declined" with comments such as these:
- "No resources for it in (team name)"
- "We won't have the resources to work on this anytime soon."
- "I do not plan to work on this any time soon."
Can we perhaps agree that the "Declined" status shouldn't be used like this?
"Declined" should be valid when:
- The component is no longer maintained (this is often done as
mass-declining).
- A product manager, a developer, or any other sensible stakeholder thinks
that doing the task as proposed is a bad idea. There are also variants of this:
- The person who filed the tasks misunderstood what the software component
is supposed to do and had wrong expectations.
- The person who filed the tasks identified a real problem, but another
task proposes a better solution.
It's quite possible that some people will disagree with the decision to mark a particular task as "Declined", but the reasons above are legitimate explanations.
However, if the task suggests a valid idea, but the reason for declining is that a team or a person doesn't plan to work on it because of lack of resources or different near-term priorities, it's quite problematic to mark it as Declined.
It's possible to reopen tasks, of course, but nevertheless "Declined" gives a somewhat permanent feeling, and may cause good ideas to get lost.
So can we perhaps decide that such tasks should just remain Open? Maybe with a Lowest priority, maybe in something like a "Freezer" or "Long term" or "Volunteer needed" column on a project workboard, but nevertheless Open?
Yes, please!
I usually reopen such tasks, but it is a little weird.
Strainu
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I agree, tasks should not be declined in such a way when tagged with component(s).
On Tue, 2 Oct 2018 at 17:31, Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
Hi,
I sometimes see WMF developers and product managers marking tasks as "Declined" with comments such as these:
- "No resources for it in (team name)"
- "We won't have the resources to work on this anytime soon."
- "I do not plan to work on this any time soon."
Can we perhaps agree that the "Declined" status shouldn't be used like this?
"Declined" should be valid when:
- The component is no longer maintained (this is often done as
mass-declining).
- A product manager, a developer, or any other sensible stakeholder thinks
that doing the task as proposed is a bad idea. There are also variants of this:
- The person who filed the tasks misunderstood what the software component
is supposed to do and had wrong expectations.
- The person who filed the tasks identified a real problem, but another
task proposes a better solution.
It's quite possible that some people will disagree with the decision to mark a particular task as "Declined", but the reasons above are legitimate explanations.
However, if the task suggests a valid idea, but the reason for declining is that a team or a person doesn't plan to work on it because of lack of resources or different near-term priorities, it's quite problematic to mark it as Declined.
It's possible to reopen tasks, of course, but nevertheless "Declined" gives a somewhat permanent feeling, and may cause good ideas to get lost.
So can we perhaps decide that such tasks should just remain Open? Maybe with a Lowest priority, maybe in something like a "Freezer" or "Long term" or "Volunteer needed" column on a project workboard, but nevertheless Open?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Declined tasks also usually do not appear in any searches by volunteers looking for tasks, which would be sad as the original reason for declining may be "no resources", declining the task effectively makes it impossible for these resources to find it, usually.
-----Ursprüngliche Nachricht----- Von: Wikitech-l wikitech-l-bounces@lists.wikimedia.org Im Auftrag von Amir E. Aharoni Gesendet: Dienstag, 2. Oktober 2018 18:31 An: Wikimedia developers wikitech-l@lists.wikimedia.org Betreff: [Wikitech-l] problematic use of "Declined" in Phabricator
Hi,
I sometimes see WMF developers and product managers marking tasks as "Declined" with comments such as these: * "No resources for it in (team name)" * "We won't have the resources to work on this anytime soon." * "I do not plan to work on this any time soon."
Can we perhaps agree that the "Declined" status shouldn't be used like this?
"Declined" should be valid when: * The component is no longer maintained (this is often done as mass-declining). * A product manager, a developer, or any other sensible stakeholder thinks that doing the task as proposed is a bad idea. There are also variants of this: * The person who filed the tasks misunderstood what the software component is supposed to do and had wrong expectations. * The person who filed the tasks identified a real problem, but another task proposes a better solution.
It's quite possible that some people will disagree with the decision to mark a particular task as "Declined", but the reasons above are legitimate explanations.
However, if the task suggests a valid idea, but the reason for declining is that a team or a person doesn't plan to work on it because of lack of resources or different near-term priorities, it's quite problematic to mark it as Declined.
It's possible to reopen tasks, of course, but nevertheless "Declined" gives a somewhat permanent feeling, and may cause good ideas to get lost.
So can we perhaps decide that such tasks should just remain Open? Maybe with a Lowest priority, maybe in something like a "Freezer" or "Long term" or "Volunteer needed" column on a project workboard, but nevertheless Open?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I agree with Amir’s understanding. "Declined” is basically for ideas whose proper timing is never. Valid ideas that we just aren’t going to work on any time soon should go in a backlog or freezer or some such, where they can await until some future project or other development makes them relevant (at least theoretically).
All of which does raise a slightly different question: I am much less clear on what the exact difference is between “Invalid” and “Declined.” Thoughts?
Best, Joe _____________________
Joe Matazzoni Product Manager, Collaboration Wikimedia Foundation, San Francisco mobile 202.744.7910 jmatazzoni@wikimedia.org
"Imagine a world in which every single human being can freely share in the sum of all knowledge."
On Oct 2, 2018, at 9:31 AM, Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
Hi,
I sometimes see WMF developers and product managers marking tasks as "Declined" with comments such as these:
- "No resources for it in (team name)"
- "We won't have the resources to work on this anytime soon."
- "I do not plan to work on this any time soon."
Can we perhaps agree that the "Declined" status shouldn't be used like this?
"Declined" should be valid when:
- The component is no longer maintained (this is often done as
mass-declining).
- A product manager, a developer, or any other sensible stakeholder thinks
that doing the task as proposed is a bad idea. There are also variants of this:
- The person who filed the tasks misunderstood what the software component
is supposed to do and had wrong expectations.
- The person who filed the tasks identified a real problem, but another
task proposes a better solution.
It's quite possible that some people will disagree with the decision to mark a particular task as "Declined", but the reasons above are legitimate explanations.
However, if the task suggests a valid idea, but the reason for declining is that a team or a person doesn't plan to work on it because of lack of resources or different near-term priorities, it's quite problematic to mark it as Declined.
It's possible to reopen tasks, of course, but nevertheless "Declined" gives a somewhat permanent feeling, and may cause good ideas to get lost.
So can we perhaps decide that such tasks should just remain Open? Maybe with a Lowest priority, maybe in something like a "Freezer" or "Long term" or "Volunteer needed" column on a project workboard, but nevertheless Open?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I agree, which raises a question why so many map related legitimate used requests were closed recently as declined, and with a comment that there is no resources to work on them
On Tue, Oct 2, 2018, 17:51 Joe Matazzoni jmatazzoni@wikimedia.org wrote:
I agree with Amir’s understanding. "Declined” is basically for ideas whose proper timing is never. Valid ideas that we just aren’t going to work on any time soon should go in a backlog or freezer or some such, where they can await until some future project or other development makes them relevant (at least theoretically).
All of which does raise a slightly different question: I am much less clear on what the exact difference is between “Invalid” and “Declined.” Thoughts?
Best, Joe _____________________
Joe Matazzoni Product Manager, Collaboration Wikimedia Foundation, San Francisco mobile 202.744.7910 jmatazzoni@wikimedia.org
"Imagine a world in which every single human being can freely share in the sum of all knowledge."
On Oct 2, 2018, at 9:31 AM, Amir E. Aharoni <
amir.aharoni@mail.huji.ac.il> wrote:
Hi,
I sometimes see WMF developers and product managers marking tasks as "Declined" with comments such as these:
- "No resources for it in (team name)"
- "We won't have the resources to work on this anytime soon."
- "I do not plan to work on this any time soon."
Can we perhaps agree that the "Declined" status shouldn't be used like
this?
"Declined" should be valid when:
- The component is no longer maintained (this is often done as
mass-declining).
- A product manager, a developer, or any other sensible stakeholder
thinks
that doing the task as proposed is a bad idea. There are also variants of this:
- The person who filed the tasks misunderstood what the software
component
is supposed to do and had wrong expectations.
- The person who filed the tasks identified a real problem, but another
task proposes a better solution.
It's quite possible that some people will disagree with the decision to mark a particular task as "Declined", but the reasons above are
legitimate
explanations.
However, if the task suggests a valid idea, but the reason for declining
is
that a team or a person doesn't plan to work on it because of lack of resources or different near-term priorities, it's quite problematic to
mark
it as Declined.
It's possible to reopen tasks, of course, but nevertheless "Declined"
gives
a somewhat permanent feeling, and may cause good ideas to get lost.
So can we perhaps decide that such tasks should just remain Open? Maybe with a Lowest priority, maybe in something like a "Freezer" or "Long
term"
or "Volunteer needed" column on a project workboard, but nevertheless
Open?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore _______________________________________________ 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
+1 that we shouldn't close valid bugs.
Assuming nobody brings up objections, here's a nice place to document new consensus: https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle
FWIW, that page is discoverable from: https://www.mediawiki.org/wiki/Phabricator/Project_management#Closing_a_task
-Adam
On Tue, Oct 2, 2018 at 9:51 AM Joe Matazzoni jmatazzoni@wikimedia.org wrote:
I agree with Amir’s understanding. "Declined” is basically for ideas whose proper timing is never. Valid ideas that we just aren’t going to work on any time soon should go in a backlog or freezer or some such, where they can await until some future project or other development makes them relevant (at least theoretically).
All of which does raise a slightly different question: I am much less clear on what the exact difference is between “Invalid” and “Declined.” Thoughts?
Best, Joe _____________________
Joe Matazzoni Product Manager, Collaboration Wikimedia Foundation, San Francisco mobile 202.744.7910 <(202)%20744-7910> jmatazzoni@wikimedia.org
"Imagine a world in which every single human being can freely share in the sum of all knowledge."
On Oct 2, 2018, at 9:31 AM, Amir E. Aharoni <
amir.aharoni@mail.huji.ac.il> wrote:
Hi,
I sometimes see WMF developers and product managers marking tasks as "Declined" with comments such as these:
- "No resources for it in (team name)"
- "We won't have the resources to work on this anytime soon."
- "I do not plan to work on this any time soon."
Can we perhaps agree that the "Declined" status shouldn't be used like
this?
"Declined" should be valid when:
- The component is no longer maintained (this is often done as
mass-declining).
- A product manager, a developer, or any other sensible stakeholder
thinks
that doing the task as proposed is a bad idea. There are also variants of this:
- The person who filed the tasks misunderstood what the software
component
is supposed to do and had wrong expectations.
- The person who filed the tasks identified a real problem, but another
task proposes a better solution.
It's quite possible that some people will disagree with the decision to mark a particular task as "Declined", but the reasons above are
legitimate
explanations.
However, if the task suggests a valid idea, but the reason for declining
is
that a team or a person doesn't plan to work on it because of lack of resources or different near-term priorities, it's quite problematic to
mark
it as Declined.
It's possible to reopen tasks, of course, but nevertheless "Declined"
gives
a somewhat permanent feeling, and may cause good ideas to get lost.
So can we perhaps decide that such tasks should just remain Open? Maybe with a Lowest priority, maybe in something like a "Freezer" or "Long
term"
or "Volunteer needed" column on a project workboard, but nevertheless
Open?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore _______________________________________________ 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
Joe,
"Invalid" means something like "this is not a legitimate report; the user had mis-configured their browser". "Declined" means something like "We understand the user's request but we won't change the default font size based on the reasoning provided here."
Pine ( https://meta.wikimedia.org/wiki/User:Pine ) -------- Original message --------From: Joe Matazzoni jmatazzoni@wikimedia.org Date: 10/2/18 9:51 AM (GMT-08:00) To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] problematic use of "Declined" in Phabricator I agree with Amir’s understanding. "Declined” is basically for ideas whose proper timing is never. Valid ideas that we just aren’t going to work on any time soon should go in a backlog or freezer or some such, where they can await until some future project or other development makes them relevant (at least theoretically).
All of which does raise a slightly different question: I am much less clear on what the exact difference is between “Invalid” and “Declined.” Thoughts?
Best, Joe _____________________
Joe Matazzoni Product Manager, Collaboration Wikimedia Foundation, San Francisco mobile 202.744.7910 jmatazzoni@wikimedia.org
"Imagine a world in which every single human being can freely share in the sum of all knowledge."
On Oct 2, 2018, at 9:31 AM, Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
Hi,
I sometimes see WMF developers and product managers marking tasks as "Declined" with comments such as these:
- "No resources for it in (team name)"
- "We won't have the resources to work on this anytime soon."
- "I do not plan to work on this any time soon."
Can we perhaps agree that the "Declined" status shouldn't be used like this?
"Declined" should be valid when:
- The component is no longer maintained (this is often done as
mass-declining).
- A product manager, a developer, or any other sensible stakeholder thinks
that doing the task as proposed is a bad idea. There are also variants of this:
- The person who filed the tasks misunderstood what the software component
is supposed to do and had wrong expectations.
- The person who filed the tasks identified a real problem, but another
task proposes a better solution.
It's quite possible that some people will disagree with the decision to mark a particular task as "Declined", but the reasons above are legitimate explanations.
However, if the task suggests a valid idea, but the reason for declining is that a team or a person doesn't plan to work on it because of lack of resources or different near-term priorities, it's quite problematic to mark it as Declined.
It's possible to reopen tasks, of course, but nevertheless "Declined" gives a somewhat permanent feeling, and may cause good ideas to get lost.
So can we perhaps decide that such tasks should just remain Open? Maybe with a Lowest priority, maybe in something like a "Freezer" or "Long term" or "Volunteer needed" column on a project workboard, but nevertheless Open?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore _______________________________________________ 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
Declined = WONTFIX (e.g. if some talented developer wrote a patch, and the patch was perfect, you would still -2 it because the functionality is not wanted/stupid/etc)
Invalid = not a real bug. That should include things like spam, stuff where the reporter is mistaken ( can't reproduce or if someone say reports a sharepoint bug)
I think the defining difference is its possible to write a patch for a declined bug, even though it would be rejected, where an invalid bug by definition is unfixable.
Just my 2 cents, others may have different definitions.
-- Brian
p.s. ive never liked the "need volunteer" term for lowest priority - I have always felt it had offensive implications as if volunteer time isnt as important so they get the low priority bugs.
On Tuesday, October 2, 2018, Joe Matazzoni jmatazzoni@wikimedia.org wrote:
I agree with Amir’s understanding. "Declined” is basically for ideas
whose proper timing is never. Valid ideas that we just aren’t going to work on any time soon should go in a backlog or freezer or some such, where they can await until some future project or other development makes them relevant (at least theoretically).
All of which does raise a slightly different question: I am much less
clear on what the exact difference is between “Invalid” and “Declined.” Thoughts?
Best, Joe _____________________
Joe Matazzoni Product Manager, Collaboration Wikimedia Foundation, San Francisco mobile 202.744.7910 jmatazzoni@wikimedia.org
"Imagine a world in which every single human being can freely share in
the sum of all knowledge."
On Oct 2, 2018, at 9:31 AM, Amir E. Aharoni amir.aharoni@mail.huji.ac.il
wrote:
Hi,
I sometimes see WMF developers and product managers marking tasks as "Declined" with comments such as these:
- "No resources for it in (team name)"
- "We won't have the resources to work on this anytime soon."
- "I do not plan to work on this any time soon."
Can we perhaps agree that the "Declined" status shouldn't be used like
this?
"Declined" should be valid when:
- The component is no longer maintained (this is often done as
mass-declining).
- A product manager, a developer, or any other sensible stakeholder
thinks
that doing the task as proposed is a bad idea. There are also variants of this:
- The person who filed the tasks misunderstood what the software
component
is supposed to do and had wrong expectations.
- The person who filed the tasks identified a real problem, but another
task proposes a better solution.
It's quite possible that some people will disagree with the decision to mark a particular task as "Declined", but the reasons above are
legitimate
explanations.
However, if the task suggests a valid idea, but the reason for declining
is
that a team or a person doesn't plan to work on it because of lack of resources or different near-term priorities, it's quite problematic to
mark
it as Declined.
It's possible to reopen tasks, of course, but nevertheless "Declined"
gives
a somewhat permanent feeling, and may cause good ideas to get lost.
So can we perhaps decide that such tasks should just remain Open? Maybe with a Lowest priority, maybe in something like a "Freezer" or "Long
term"
or "Volunteer needed" column on a project workboard, but nevertheless
Open?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore _______________________________________________ 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
I think I can provide some context here, because this really seems to be about something specific. The Reading Infrastructure team recently inherited maintenance responsibility for the Wikimedia maps stack, resourced on a very limited basis. Along with that, we inherited a backlog of many hundreds of tasks, many of which have seen no activity for years. For the past couple of months, a few of us have spent an hour each week trying to work through the backlog trying to triage all of these. In the course of these grooming meetings, we have closed more than a few tasks based on a combination of not having the resources to work on them, and it not seeming likely that anyone else will, either; the theory here is that it can better reflect reality to openly decline a task than to let it languish in a backlog indefinitely.
If this contravenes the relevant norms, I apologize. If you were upset by the closing of what you believe to be a valid maps ticket, please feel free to reopen. Thanks.
On Tue, Oct 2, 2018 at 10:06 PM Brian Wolff bawolff@gmail.com wrote:
Declined = WONTFIX (e.g. if some talented developer wrote a patch, and the patch was perfect, you would still -2 it because the functionality is not wanted/stupid/etc)
Invalid = not a real bug. That should include things like spam, stuff where the reporter is mistaken ( can't reproduce or if someone say reports a sharepoint bug)
I think the defining difference is its possible to write a patch for a declined bug, even though it would be rejected, where an invalid bug by definition is unfixable.
Just my 2 cents, others may have different definitions.
-- Brian
p.s. ive never liked the "need volunteer" term for lowest priority - I have always felt it had offensive implications as if volunteer time isnt as important so they get the low priority bugs.
On Tuesday, October 2, 2018, Joe Matazzoni jmatazzoni@wikimedia.org wrote:
I agree with Amir’s understanding. "Declined” is basically for ideas
whose proper timing is never. Valid ideas that we just aren’t going to work on any time soon should go in a backlog or freezer or some such, where they can await until some future project or other development makes them relevant (at least theoretically).
All of which does raise a slightly different question: I am much less
clear on what the exact difference is between “Invalid” and “Declined.” Thoughts?
Best, Joe _____________________
Joe Matazzoni Product Manager, Collaboration Wikimedia Foundation, San Francisco mobile 202.744.7910 jmatazzoni@wikimedia.org
"Imagine a world in which every single human being can freely share in
the sum of all knowledge."
On Oct 2, 2018, at 9:31 AM, Amir E. Aharoni <
amir.aharoni@mail.huji.ac.il> wrote:
Hi,
I sometimes see WMF developers and product managers marking tasks as "Declined" with comments such as these:
- "No resources for it in (team name)"
- "We won't have the resources to work on this anytime soon."
- "I do not plan to work on this any time soon."
Can we perhaps agree that the "Declined" status shouldn't be used like
this?
"Declined" should be valid when:
- The component is no longer maintained (this is often done as
mass-declining).
- A product manager, a developer, or any other sensible stakeholder
thinks
that doing the task as proposed is a bad idea. There are also variants
of
this:
- The person who filed the tasks misunderstood what the software
component
is supposed to do and had wrong expectations.
- The person who filed the tasks identified a real problem, but another
task proposes a better solution.
It's quite possible that some people will disagree with the decision to mark a particular task as "Declined", but the reasons above are
legitimate
explanations.
However, if the task suggests a valid idea, but the reason for declining
is
that a team or a person doesn't plan to work on it because of lack of resources or different near-term priorities, it's quite problematic to
mark
it as Declined.
It's possible to reopen tasks, of course, but nevertheless "Declined"
gives
a somewhat permanent feeling, and may cause good ideas to get lost.
So can we perhaps decide that such tasks should just remain Open? Maybe with a Lowest priority, maybe in something like a "Freezer" or "Long
term"
or "Volunteer needed" column on a project workboard, but nevertheless
Open?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore _______________________________________________ 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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, 2018-10-02 at 22:24 +0500, Michael Holloway wrote:
I think I can provide some context here, because this really seems to be about something specific. The Reading Infrastructure team recently inherited maintenance responsibility for the Wikimedia maps stack, resourced on a very limited basis. Along with that, we inherited a backlog of many hundreds of tasks, many of which have seen no activity for years. For the past couple of months, a few of us have spent an hour each week trying to work through the backlog trying to triage all of these. In the course of these grooming meetings, we have closed more than a few tasks based on a combination of not having the resources to work on them, and it not seeming likely that anyone else will, either; the theory here is that it can better reflect reality to openly decline a task than to let it languish in a backlog indefinitely.
If this contravenes the relevant norms, I apologize. If you were upset by the closing of what you believe to be a valid maps ticket, please feel free to reopen. Thanks.
Has it been considered to keep tasks open and set the Priority field to 'Lowest'? Plus potentially add the #Needs-volunteer project tag (though nobody knows what that tag is supposed to exactly imply, I'm afraid)? *If* separate project tags for "the software code base" vs "our team's workboard" exist, it could also be an option to remove the "team project tag" with a comment that the team does not have resources to work on this. The latter completely depends on team workflows as some teams have Herald filter rules to automatically add their "team project tag" to tasks associated with a "software code base" tag they maintain.
In general, it is possible to exclude tasks with a certain priority or certain tag from search results and from being displayed on workboards.
And on a high meta-level, hoping to offer some perspective:
Many people who use task tracking systems in collaborative free and open source projects are not used to a single authority. This is directly related to not necessarily realizing that product management requires saying No/Wontfix/Declined to many bugs and ideas. In theory, when the code base is public and welcomes contributions, a random stranger could drive by and provide a patch for a low[est] priority ticket that has been open for years. It's unlikely but not impossible. That's why some people might expect tickets to remain open if those tickets are not "completely out of scope" for the project.
andre
I'm not sure it is a so focused issue. A recent unrelated ticket I made was closed with the "no resource to waste on that" by a product owner.
A first thing is that I want to work on this issue, and would find that useful to use phabricator to track that task even if no specific resource would be dedicated to it beyond my own attention. On that regard, I red again the documentation and concluded that it was fine to reopen it in regard to what it is stated on ticket status life cycles. So far so good, I would say.
On the other hand, I discovered in the process that for some other people in the community phabricator is perceived as an hostile place, out of what they feel as part of "their" community. Actually, to the point that starting a proposal on phabricator might be interpreted as an attempt to enforce ideas without and against the consent of the community, rather than a call to give feedback and make evolve ideas together, and thus despite an immediate communication on the ticket creation.
That's what make me think that the issue discussed here is far deeper and have a great psychological effect on the cohesion of the Wikimedia community.
Cheers
Le 2 octobre 2018 19:24:23 GMT+02:00, Michael Holloway mholloway@wikimedia.org a écrit :
I think I can provide some context here, because this really seems to be about something specific. The Reading Infrastructure team recently inherited maintenance responsibility for the Wikimedia maps stack, resourced on a very limited basis. Along with that, we inherited a backlog of many hundreds of tasks, many of which have seen no activity for years. For the past couple of months, a few of us have spent an hour each week trying to work through the backlog trying to triage all of these. In the course of these grooming meetings, we have closed more than a few tasks based on a combination of not having the resources to work on them, and it not seeming likely that anyone else will, either; the theory here is that it can better reflect reality to openly decline a task than to let it languish in a backlog indefinitely.
If this contravenes the relevant norms, I apologize. If you were upset by the closing of what you believe to be a valid maps ticket, please feel free to reopen. Thanks.
On Tue, Oct 2, 2018 at 10:06 PM Brian Wolff bawolff@gmail.com wrote:
Declined = WONTFIX (e.g. if some talented developer wrote a patch,
and the
patch was perfect, you would still -2 it because the functionality is
not
wanted/stupid/etc)
Invalid = not a real bug. That should include things like spam, stuff
where
the reporter is mistaken ( can't reproduce or if someone say reports
a
sharepoint bug)
I think the defining difference is its possible to write a patch for
a
declined bug, even though it would be rejected, where an invalid bug
by
definition is unfixable.
Just my 2 cents, others may have different definitions.
-- Brian
p.s. ive never liked the "need volunteer" term for lowest priority -
I have
always felt it had offensive implications as if volunteer time isnt
as
important so they get the low priority bugs.
On Tuesday, October 2, 2018, Joe Matazzoni jmatazzoni@wikimedia.org wrote:
I agree with Amir’s understanding. "Declined” is basically for
ideas
whose proper timing is never. Valid ideas that we just aren’t going
to
work on any time soon should go in a backlog or freezer or some such,
where
they can await until some future project or other development makes
them
relevant (at least theoretically).
All of which does raise a slightly different question: I am much
less
clear on what the exact difference is between “Invalid” and
“Declined.”
Thoughts?
Best, Joe _____________________
Joe Matazzoni Product Manager, Collaboration Wikimedia Foundation, San Francisco mobile 202.744.7910 jmatazzoni@wikimedia.org
"Imagine a world in which every single human being can freely share
in
the sum of all knowledge."
On Oct 2, 2018, at 9:31 AM, Amir E. Aharoni <
amir.aharoni@mail.huji.ac.il> wrote:
Hi,
I sometimes see WMF developers and product managers marking tasks
as
"Declined" with comments such as these:
- "No resources for it in (team name)"
- "We won't have the resources to work on this anytime soon."
- "I do not plan to work on this any time soon."
Can we perhaps agree that the "Declined" status shouldn't be used
like
this?
"Declined" should be valid when:
- The component is no longer maintained (this is often done as
mass-declining).
- A product manager, a developer, or any other sensible
stakeholder
thinks
that doing the task as proposed is a bad idea. There are also
variants
of
this:
- The person who filed the tasks misunderstood what the software
component
is supposed to do and had wrong expectations.
- The person who filed the tasks identified a real problem, but
another
task proposes a better solution.
It's quite possible that some people will disagree with the
decision to
mark a particular task as "Declined", but the reasons above are
legitimate
explanations.
However, if the task suggests a valid idea, but the reason for
declining
is
that a team or a person doesn't plan to work on it because of lack
of
resources or different near-term priorities, it's quite
problematic to
mark
it as Declined.
It's possible to reopen tasks, of course, but nevertheless
"Declined"
gives
a somewhat permanent feeling, and may cause good ideas to get
lost.
So can we perhaps decide that such tasks should just remain Open?
Maybe
with a Lowest priority, maybe in something like a "Freezer" or
"Long
term"
or "Volunteer needed" column on a project workboard, but
nevertheless
Open?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore _______________________________________________ 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
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
În mie., 3 oct. 2018 la 19:08, Mathieu Lovato Stumpf Guntz psychoslave@culture-libre.org a scris:
On the other hand, I discovered in the process that for some other people in the community phabricator is perceived as an hostile place, out of what they feel as part of "their" community. Actually, to the point that starting a proposal on phabricator might be interpreted as an attempt to enforce ideas without and against the consent of the community, rather than a call to give feedback and make evolve ideas together, and thus despite an immediate communication on the ticket creation.
That's a totally orthogonal problem that existed from the bugzilla days. Some people consider bug tracking as a "dev" activity that they don't know anything about, others have difficulties communicating in English and finally some just consider the WMF evil and want nothing to do with it. Using Phabricator to track bugs and features in a certain way (or at all) doesn't seem to have a lot to do with this (unless there is some proof to the contrary that I'm not aware of).
The problem Amir brought up mainly affects people that already use Phabricator.
Strainu
Regarding 'A recent unrelated ticket I made was closed with the "no resource to waste on that" by a product owner.': I think that civil messages explaining why a ticket won't be addressed would be helpful, as would civil messages explaining why tasks are being moved to a "freezer", instead of moves, closures, etc. with no explanation or with somewhat insulting comments. Messages don't need to be elaborate, and can be copypasted, so long as they explain in civil terms what's happening and why. Keep in mind that some people who submit tickets may not natively communicate in English, and may have little familiarity with the Wikimedia use of Phabricator.
Regarding where to discuss proposals that address issues that have been raised in this thread, as I said earlier, I suggest a wiki talk page.
On Tue, 2018-10-02 at 17:05 +0000, Brian Wolff wrote:
Declined = WONTFIX (e.g. if some talented developer wrote a patch, and the patch was perfect, you would still -2 it because the functionality is not wanted/stupid/etc)
Invalid = not a real bug. That should include things like spam, stuff where the reporter is mistaken ( can't reproduce or if someone say reports a sharepoint bug)
I think the defining difference is its possible to write a patch for a declined bug, even though it would be rejected, where an invalid bug by definition is unfixable.
Just my 2 cents, others may have different definitions.
https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle
andre
Hi!
All of which does raise a slightly different question: I am much less clear on what the exact difference is between “Invalid” and “Declined.” Thoughts?
I usually use Invalid where the description of the task does not really describe the problem (or a problem) - e.g. it was a user error, misconfiguration, misunderstanding about how it should have worked, transient condition that has passed and we can not do anything about it, something that is outside of realm of possibilities for us to do (e.g. "fix copyright laws"), a task created by mistake, etc. For TODO tasks, Invalid would be when the task is describing something that can not be done at all (at least by us), or would not produce any desirable result.
Declined is when it describes a valid task in general, but we are not going to do it because of reasons.
*nods* I think the root problem is that the phabricator task system does double duty as both an *issue reporting system* for users and a *task tracker* for devs.
An issue reporting system should capture all actual problems and all actual suggestions, and is meant to provide visibility for the devs into the world of users. A task tracker should capture only things that are, or are planned to be, worked on and is a work planning tool for the devs. Secondarily if open, the task tracker provides visibility for the users into the world of devs.
This mixup of concerns is endemic in open source software development, unfortunately, and leads to exactly the sorts of conflicts you mention.
One way to handle this in a mixed single tracker environment is to use a state marker such as a backlog column in a workboard -- don't decline, move it to the "backlog" or "someday" column. Another is to use separate project tags for general issues and specific work efforts. Put it in the general project for issues, copy it to the work project if it's being tracked in your work group.
-- brion
On Tue, Oct 2, 2018, 9:31 AM Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
Hi,
I sometimes see WMF developers and product managers marking tasks as "Declined" with comments such as these:
- "No resources for it in (team name)"
- "We won't have the resources to work on this anytime soon."
- "I do not plan to work on this any time soon."
Can we perhaps agree that the "Declined" status shouldn't be used like this?
"Declined" should be valid when:
- The component is no longer maintained (this is often done as
mass-declining).
- A product manager, a developer, or any other sensible stakeholder thinks
that doing the task as proposed is a bad idea. There are also variants of this:
- The person who filed the tasks misunderstood what the software component
is supposed to do and had wrong expectations.
- The person who filed the tasks identified a real problem, but another
task proposes a better solution.
It's quite possible that some people will disagree with the decision to mark a particular task as "Declined", but the reasons above are legitimate explanations.
However, if the task suggests a valid idea, but the reason for declining is that a team or a person doesn't plan to work on it because of lack of resources or different near-term priorities, it's quite problematic to mark it as Declined.
It's possible to reopen tasks, of course, but nevertheless "Declined" gives a somewhat permanent feeling, and may cause good ideas to get lost.
So can we perhaps decide that such tasks should just remain Open? Maybe with a Lowest priority, maybe in something like a "Freezer" or "Long term" or "Volunteer needed" column on a project workboard, but nevertheless Open?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
*very much agree with both Amir and Brion*
I've seen the same thing; something is reported as a more or less general issue, it is then picked up as a task, it is further discussed in a specific context, then closed because it does not fit the given context. But the new context wasn't part of the reported issue, which is part of the production system, it is part of some specific on-going development.
Hi!
On 10/2/18 9:57 AM, Brion Vibber wrote:
*nods* I think the root problem is that the phabricator task system does double duty as both an *issue reporting system* for users and a *task tracker* for devs.
This is probably the real root cause. But I don't think we are going to make the split anytime soon, even if we wanted to (which is not certain), and this mode of operation is very common in many organizations.
Realizing this, I think we need some mode of explicitly saying "we do not have any means to do it now or in near-term future, but we don't reject it completely and if we ever have resources or ways to do this, we might revisit this".
We kinda sorta have this with "Stalled" status and "Need volunteer" tag, but we might want to get this status more prominent and distinguish "TODO" items outside of any planning cycle and the ones that are part of the ongoing development. And document it in the lifecycle document.
On Tue, Oct 2, 2018 at 11:32 AM Stas Malyshev smalyshev@wikimedia.org wrote:
Realizing this, I think we need some mode of explicitly saying "we do not have any means to do it now or in near-term future, but we don't reject it completely and if we ever have resources or ways to do this, we might revisit this".
We kinda sorta have this with "Stalled" status and "Need volunteer" tag, but we might want to get this status more prominent and distinguish "TODO" items outside of any planning cycle and the ones that are part of the ongoing development. And document it in the lifecycle document.
I have found that setting the priority to "lowest" is the closest thing we have to "this is a valid task but we are not going to invest paid time into it."
---- James Hare Associate Product Manager Wikimedia Foundation https://wikimediafoundation.org
I agree with this approach, and also with moving tasks to a "freezer".
I support depreciating the use of "needs volunteer (developer)".
Pine ( https://meta.wikimedia.org/wiki/User:Pine ) -------- Original message --------From: James Hare jhare@wikimedia.org Date: 10/2/18 11:41 AM (GMT-08:00) To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] problematic use of "Declined" in Phabricator On Tue, Oct 2, 2018 at 11:32 AM Stas Malyshev smalyshev@wikimedia.org wrote:
Realizing this, I think we need some mode of explicitly saying "we do not have any means to do it now or in near-term future, but we don't reject it completely and if we ever have resources or ways to do this, we might revisit this".
We kinda sorta have this with "Stalled" status and "Need volunteer" tag, but we might want to get this status more prominent and distinguish "TODO" items outside of any planning cycle and the ones that are part of the ongoing development. And document it in the lifecycle document.
I have found that setting the priority to "lowest" is the closest thing we have to "this is a valid task but we are not going to invest paid time into it."
---- James Hare Associate Product Manager Wikimedia Foundation https://wikimediafoundation.org _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
We could also create a global tag called freezer / room101 (😉) to help developers to do this filtering. It would also allow us to get a high level overview of under resourced projects which i suspect would be helpful with planning and finding stewards for certain projects.
Without such a tag projects are forced to create their own tags/milestones/columns to manage these tasks (my team has done just this)
On Tue, Oct 2, 2018, 12:05 PM Pine W wiki.pine@gmail.com wrote:
I agree with this approach, and also with moving tasks to a "freezer".
I support depreciating the use of "needs volunteer (developer)".
Pine ( https://meta.wikimedia.org/wiki/User:Pine ) -------- Original message --------From: James Hare jhare@wikimedia.org Date: 10/2/18 11:41 AM (GMT-08:00) To: Wikimedia developers < wikitech-l@lists.wikimedia.org> Subject: Re: [Wikitech-l] problematic use of "Declined" in Phabricator On Tue, Oct 2, 2018 at 11:32 AM Stas Malyshev smalyshev@wikimedia.org wrote:
Realizing this, I think we need some mode of explicitly saying "we do not have any means to do it now or in near-term future, but we don't reject it completely and if we ever have resources or ways to do this, we might revisit this".
We kinda sorta have this with "Stalled" status and "Need volunteer" tag, but we might want to get this status more prominent and distinguish "TODO" items outside of any planning cycle and the ones that are part of the ongoing development. And document it in the lifecycle document.
I have found that setting the priority to "lowest" is the closest thing we have to "this is a valid task but we are not going to invest paid time into it."
James Hare Associate Product Manager Wikimedia Foundation https://wikimediafoundation.org _______________________________________________ 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
I think we are misusing the term "priority" here. Priority for whom? Setting something to "lowest" priority implies that users do not care about the item. Unbreak now implies users need it fixed right away. "we have no resources" does not mean its not needed, it just means WMF does not view it as a priority, which might align, but frequently misalign with the user's needs.
I suggest we use dashboard columns for the planning activities, while keeping the tasks themselves fully under "requester's" control. E.g. let the community decide what is more important, but use dashboards for team work planning. This way, if a volunteer developer wants to contribute, they would look for the highest-demanded bugs that don't have active status in any teams.
On Tue, Oct 2, 2018 at 7:32 PM Stas Malyshev smalyshev@wikimedia.org wrote:
Hi!
On 10/2/18 9:57 AM, Brion Vibber wrote:
*nods* I think the root problem is that the phabricator task system does double duty as both an *issue reporting system* for users and a *task tracker* for devs.
This is probably the real root cause. But I don't think we are going to make the split anytime soon, even if we wanted to (which is not certain), and this mode of operation is very common in many organizations.
Realizing this, I think we need some mode of explicitly saying "we do not have any means to do it now or in near-term future, but we don't reject it completely and if we ever have resources or ways to do this, we might revisit this".
We kinda sorta have this with "Stalled" status and "Need volunteer" tag, but we might want to get this status more prominent and distinguish "TODO" items outside of any planning cycle and the ones that are part of the ongoing development. And document it in the lifecycle document.
-- Stas Malyshev smalyshev@wikimedia.org
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi!
I think we are misusing the term "priority" here. Priority for whom?
For whoever is responsible for the planning. Which in most cases is the WMF team that is tagged, though if it's a project that belongs to another team (or person), then it's this team's (or person's) planning.
Setting something to "lowest" priority implies that users do not care about the item.
No, I don't think this is what it means. It should mean the planning team does not have any immediate plans or resources to dedicate to it. That's the consequence of using Phabricator as development tracking tool. It's developer's priorities - which are supposed to mirror users' ones, to a reasonable degree, but are not the same thing.
I suggest we use dashboard columns for the planning activities, while keeping the tasks themselves fully under "requester's" control. E.g. let
I don't think it would help developers' work. If we need a mechanism to track user's priorities in Phabricator, we should create one, but I don't think breaking existing and used mechanism for tracking development priorities is a good way to achieve that. Columns *are* used for planning, but in a different way.
the community decide what is more important, but use dashboards for team work planning. This way, if a volunteer developer wants to contribute, they would look for the highest-demanded bugs that don't have active status in any teams.
I recognize that highlighting issues that volunteers should concentrate on is a valid need. But I don't think reusing the same mechanism as ongoing development tracking is using now is going to be good. It may get very confusing. We should try to find other way to specify that.
On Tue, 2018-10-02 at 20:43 +0100, Yuri Astrakhan wrote:
I think we are misusing the term "priority" here. Priority for whom? Setting something to "lowest" priority implies that users do not care about the item.
It does not, as "users" do not prioritize what developers work on. https://www.mediawiki.org/wiki/Phabricator/Project_management#Setting_task_p...
I suggest we use dashboard columns for the planning activities, while keeping the tasks themselves fully under "requester's" control. E.g. let the community decide what is more important
IMHO software development is not a popularity contest.
For completeness, some attempts to make communities influence development priorities exist, such as https://meta.wikimedia.org/wiki/2018_Community_Wishlist_Survey
Furthermore, if you are aware of a functioning system to "let the community decide" which also covers the needs of people we want to attract as new future members of "the community" (we have about 900 Wikimedia sites with different needs), which takes self-selection bias into consideration: I'd love to get more info. :)
Thanks, andre
On Tue, Oct 2, 2018 at 9:57 AM Brion Vibber bvibber@wikimedia.org wrote:
*nods* I think the root problem is that the phabricator task system does double duty as both an *issue reporting system* for users and a *task tracker* for devs.
IMO that kind of double duty is normal for all software development project management systems (and having to track bugs in two separate systems was in fact rather painful in the dark ages when we had Bugzilla + some team-specific external task management system). Rather, the problem is that it's a task management system used by many different groups (including volunteers) with overlapping scopes. Prioritization decisions are specific to a team (or an organization at best) while Phabricator task status and priority are global settings. This problem comes up in non-volunteer contexts as well, when a task is relevant to two teams and a high priority for one but low / zero for the other.
So IMO the sanest approach is for all teams to come up with ways to mark prioritization that are local to their Phabricator projects (which typically means using a team workboard for prioritization and having some kind of "we don't intend to work on this" column).
Setting tasks to stalled when no one is planning to work on them would be a reasonable practice if we decide to consistently use the stalled status that way, but today it's used as "blocked" instead.
Brion Vibber wrote:
*nods* I think the root problem is that the phabricator task system does double duty as both an *issue reporting system* for users and a *task tracker* for devs.
An issue reporting system should capture all actual problems and all actual suggestions, and is meant to provide visibility for the devs into the world of users. A task tracker should capture only things that are, or are planned to be, worked on and is a work planning tool for the devs. Secondarily if open, the task tracker provides visibility for the users into the world of devs.
This mixup of concerns is endemic in open source software development, unfortunately, and leads to exactly the sorts of conflicts you mention.
I agree with there being multiple use-cases for Phabricator. I don't agree that it's necessarily a problem. User feedback and bug reports often directly lead to and can directly influence developer work. Mixing the two groups is also a decent means of developing community and rapport between developers and users in a shared space.
I also don't agree that a task tracker needs to only capture items to be worked on. Filters, tags, and other user interface tweaks can address the competing use-cases well enough, in my opinion, and as you note. The number of tasks in the issue tracker is somewhat immaterial, just as the English Wikipedia having over five million articles is immaterial, when you're just reading one.
Another way to frame your root problem would be volunteer use versus corporate use. In my experience, it's very common for valid bugs and issues to be closed mercilessly in corporate issue trackers, as business priorities shift and staff turns over. We may need to make it clearer and more explicit that the Phabricator installation at phabricator.wikimedia.org is for all members of the Wikimedia movement.
MZMcBride
I'm grateful for this largely civil and productive discussion. I'd like to suggest that the multiple sub-topics being discussed here might be easier to follow if the entire discussion is moved to a wiki talk page, such as on MediaWiki.org. I am not attempting to halt discussion or to tell people to stop writing to the mailing list; moving to a wiki talk page is just a suggestion.
Thanks,
My two cents: I would personally make those type of tickets as "stalled", "stalled" basically for me means blocked and these type of tasks are blocked on human resources, some miracles might happen and we might end up having enough resources to unblock it but until that day it's stalled IMO.
OTOH there are tickets that we don't have resources to work on it and we never will, imagine a ticket with title "Rewrite mediawiki", it sounds good as lots of part of it is old but we will never have such resource to do it. IMO, we should call it declined on grounds of not having resources. Same goes for "Every user should have a personal private wiki": We don't have hardware resources for that and probably never will.
Best
On Wed, Oct 3, 2018 at 7:27 AM Pine W wiki.pine@gmail.com wrote:
I'm grateful for this largely civil and productive discussion. I'd like to suggest that the multiple sub-topics being discussed here might be easier to follow if the entire discussion is moved to a wiki talk page, such as on MediaWiki.org. I am not attempting to halt discussion or to tell people to stop writing to the mailing list; moving to a wiki talk page is just a suggestion.
Thanks,
Pine ( https://meta.wikimedia.org/wiki/User:Pine ) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Another side effect of closing a ticket with Declined, is that it doesn't show up in search (because it's closed and closed tickets are omitted by default). But if the problem or desire for the feature still exists, it is likely to be reported again by users via a new ticket and other people then have to go duplicate hunting. So that creates more duplicates to weed through.
And when I work on something, I often take a look at boards and see if there is anything else in the same area that might need work, or I use the tickets to get a feeling of the direction that people want us to go. When declined is mixed with "we can't work on this right now", that makes it a lot harder to do that as well.
So i think Stalled is better. The problem with that can be that such tickets show up in workboards, which can create a lot of load in the browser if there are a lot of tickets. If we would tag all of such tickets with something like 'need-volunteer', a team could customise their work board filter to exclude all tickets with that tag. Or simply exclude the entire status, but then you cannot effectively use it within the team either. We do have to make that need-volunteer tag somewhat better defined in the bug lifecycle and the tag's description in that case. That tag started out more as an "opportunities for volunteers". Alternative is a new "no-resourcing" tag. or something.
DJ
On Wed, Oct 3, 2018 at 1:03 PM Amir Sarabadani ladsgroup@gmail.com wrote:
My two cents: I would personally make those type of tickets as "stalled", "stalled" basically for me means blocked and these type of tasks are blocked on human resources, some miracles might happen and we might end up having enough resources to unblock it but until that day it's stalled IMO.
OTOH there are tickets that we don't have resources to work on it and we never will, imagine a ticket with title "Rewrite mediawiki", it sounds good as lots of part of it is old but we will never have such resource to do it. IMO, we should call it declined on grounds of not having resources. Same goes for "Every user should have a personal private wiki": We don't have hardware resources for that and probably never will.
Best
On Wed, Oct 3, 2018 at 7:27 AM Pine W wiki.pine@gmail.com wrote:
I'm grateful for this largely civil and productive discussion. I'd like
to
suggest that the multiple sub-topics being discussed here might be easier to follow if the entire discussion is moved to a wiki talk page, such as
on
MediaWiki.org. I am not attempting to halt discussion or to tell people
to
stop writing to the mailing list; moving to a wiki talk page is just a suggestion.
Thanks,
Pine ( https://meta.wikimedia.org/wiki/User:Pine ) _______________________________________________ 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
Just one note about "needs-volunteer". If the staff maintaining an extension don't have time to work on a problem, they may also not have time to review any changes relating to it.
If you do use this tag, I see this as an indication you are willing to take time to review any contributions relating to that task and do so until the task is seen to completion.
There is nothing I hate more than seeing volunteers submit patches to help the project and not getting any code review. Our volunteers are important.
On Wed, 3 Oct 2018 at 05:15 Derk-Jan Hartman d.j.hartman+wmf_ml@gmail.com wrote:
Another side effect of closing a ticket with Declined, is that it doesn't show up in search (because it's closed and closed tickets are omitted by default). But if the problem or desire for the feature still exists, it is likely to be reported again by users via a new ticket and other people then have to go duplicate hunting. So that creates more duplicates to weed through.
And when I work on something, I often take a look at boards and see if there is anything else in the same area that might need work, or I use the tickets to get a feeling of the direction that people want us to go. When declined is mixed with "we can't work on this right now", that makes it a lot harder to do that as well.
So i think Stalled is better. The problem with that can be that such tickets show up in workboards, which can create a lot of load in the browser if there are a lot of tickets. If we would tag all of such tickets with something like 'need-volunteer', a team could customise their work board filter to exclude all tickets with that tag. Or simply exclude the entire status, but then you cannot effectively use it within the team either. We do have to make that need-volunteer tag somewhat better defined in the bug lifecycle and the tag's description in that case. That tag started out more as an "opportunities for volunteers". Alternative is a new "no-resourcing" tag. or something.
DJ
On Wed, Oct 3, 2018 at 1:03 PM Amir Sarabadani ladsgroup@gmail.com wrote:
My two cents: I would personally make those type of tickets as "stalled", "stalled" basically for me means blocked and these type of tasks are blocked on
human
resources, some miracles might happen and we might end up having enough resources to unblock it but until that day it's stalled IMO.
OTOH there are tickets that we don't have resources to work on it and we never will, imagine a ticket with title "Rewrite mediawiki", it sounds
good
as lots of part of it is old but we will never have such resource to do
it.
IMO, we should call it declined on grounds of not having resources. Same goes for "Every user should have a personal private wiki": We don't have hardware resources for that and probably never will.
Best
On Wed, Oct 3, 2018 at 7:27 AM Pine W wiki.pine@gmail.com wrote:
I'm grateful for this largely civil and productive discussion. I'd like
to
suggest that the multiple sub-topics being discussed here might be
easier
to follow if the entire discussion is moved to a wiki talk page, such
as
on
MediaWiki.org. I am not attempting to halt discussion or to tell people
to
stop writing to the mailing list; moving to a wiki talk page is just a suggestion.
Thanks,
Pine ( https://meta.wikimedia.org/wiki/User:Pine ) _______________________________________________ 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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org