Question to WMF: Backlog on bugs

classic Classic list List threaded Threaded
87 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Stas Malyshev
Hi!

> In my experience WMF teams usually have a way to distinguish "bugs we're
> going to work on soon" and "bugs we're not planning to work on, but we'd
> accept patches". This is usually public in Phabricator, but not really
> documented.

There's the "Need volunteer" tag that I think can be used for that.
--
Stas Malyshev
[hidden email]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

John Erling Blad
It seems like some projects simply put everything coming from external
sources into deep freezer or add "need volunteer". If they respond at
all. In some cases it could be that the projects are defunc.

On Mon, Mar 11, 2019 at 9:51 PM Stas Malyshev <[hidden email]> wrote:

>
> Hi!
>
> > In my experience WMF teams usually have a way to distinguish "bugs we're
> > going to work on soon" and "bugs we're not planning to work on, but we'd
> > accept patches". This is usually public in Phabricator, but not really
> > documented.
>
> There's the "Need volunteer" tag that I think can be used for that.
> --
> Stas Malyshev
> [hidden email]
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

John Erling Blad
In reply to this post by Amir Sarabadani-2
> 2- Everything is open-source and as non-profit, there's always resource
> constraint. If it's really important to you, feel free to make a patch and
> the team would be always more than happy to review.

Wikipedia is the core product, and the users are the primary
customers. When a group of core customers request a change, then the
service provider should respond. Whether the service provider is a
non-profit doesn't really matter, the business model is not part of
the functional requirement. The service provider should simply make
sure the processes function properly.

If the service provider has resource constraints, then it must scale
the services until it gets a reasonable balance, but that does not
seem to be the case here. It is more like there are no process or the
process is defunc.

The strange thing is; for many projects the primary customers aren't
even part of a stakeholder group, the devs in the groups defines
themselves as the "product user group". That tend to skew development
from bugs to features. Perhaps that is what happen in general here,
too much techies that believe they are the primary customers.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

David Barratt
A customer, by definition (https://en.wikipedia.org/wiki/Customer)
exchanges something of value (money) for a product or service.

That does not mean that a freemium model (
https://en.wikipedia.org/wiki/Freemium) is not a valid business model.
However, if there is no exchange of value, the person consuming the free
version of the product or service, is not (yet) a customer.

If MediaWiki is the thing we give away for free, what do we charge money
for?
Are our customers successfully subsidizing our free (as in beer) software?

On Mon, Mar 11, 2019 at 7:33 PM John Erling Blad <[hidden email]> wrote:

> > 2- Everything is open-source and as non-profit, there's always resource
> > constraint. If it's really important to you, feel free to make a patch
> and
> > the team would be always more than happy to review.
>
> Wikipedia is the core product, and the users are the primary
> customers. When a group of core customers request a change, then the
> service provider should respond. Whether the service provider is a
> non-profit doesn't really matter, the business model is not part of
> the functional requirement. The service provider should simply make
> sure the processes function properly.
>
> If the service provider has resource constraints, then it must scale
> the services until it gets a reasonable balance, but that does not
> seem to be the case here. It is more like there are no process or the
> process is defunc.
>
> The strange thing is; for many projects the primary customers aren't
> even part of a stakeholder group, the devs in the groups defines
> themselves as the "product user group". That tend to skew development
> from bugs to features. Perhaps that is what happen in general here,
> too much techies that believe they are the primary customers.
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

John Erling Blad
Without the editors there would be no content, and thus no readers,
and without readers there would be no use for the software provided.
So is the actual users subsidizing the software? Definitely yes! The
content is the primary reason why we have readers. The software is
just a tool to provide the content in an accessible form to the
readers.

Whether an editor is a customer by subsidizing the product directly or
indirectly is not much of a concern, as long as there will be no
subsidizing at all, from any party – ever, without the content.

The primary customer of the software is the editors, but the primary
customer of the content is the readers.

On Tue, Mar 12, 2019 at 2:18 AM David Barratt <[hidden email]> wrote:

>
> A customer, by definition (https://en.wikipedia.org/wiki/Customer)
> exchanges something of value (money) for a product or service.
>
> That does not mean that a freemium model (
> https://en.wikipedia.org/wiki/Freemium) is not a valid business model.
> However, if there is no exchange of value, the person consuming the free
> version of the product or service, is not (yet) a customer.
>
> If MediaWiki is the thing we give away for free, what do we charge money
> for?
> Are our customers successfully subsidizing our free (as in beer) software?
>
> On Mon, Mar 11, 2019 at 7:33 PM John Erling Blad <[hidden email]> wrote:
>
> > > 2- Everything is open-source and as non-profit, there's always resource
> > > constraint. If it's really important to you, feel free to make a patch
> > and
> > > the team would be always more than happy to review.
> >
> > Wikipedia is the core product, and the users are the primary
> > customers. When a group of core customers request a change, then the
> > service provider should respond. Whether the service provider is a
> > non-profit doesn't really matter, the business model is not part of
> > the functional requirement. The service provider should simply make
> > sure the processes function properly.
> >
> > If the service provider has resource constraints, then it must scale
> > the services until it gets a reasonable balance, but that does not
> > seem to be the case here. It is more like there are no process or the
> > process is defunc.
> >
> > The strange thing is; for many projects the primary customers aren't
> > even part of a stakeholder group, the devs in the groups defines
> > themselves as the "product user group". That tend to skew development
> > from bugs to features. Perhaps that is what happen in general here,
> > too much techies that believe they are the primary customers.
> >
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Vi to
Regardless of definition-related issues, I concur editors' most
shared/fundamental needs deserve being addressed spending some money.

Vito

Il giorno mar 12 mar 2019 alle ore 11:50 John Erling Blad <[hidden email]>
ha scritto:

> Without the editors there would be no content, and thus no readers,
> and without readers there would be no use for the software provided.
> So is the actual users subsidizing the software? Definitely yes! The
> content is the primary reason why we have readers. The software is
> just a tool to provide the content in an accessible form to the
> readers.
>
> Whether an editor is a customer by subsidizing the product directly or
> indirectly is not much of a concern, as long as there will be no
> subsidizing at all, from any party – ever, without the content.
>
> The primary customer of the software is the editors, but the primary
> customer of the content is the readers.
>
> On Tue, Mar 12, 2019 at 2:18 AM David Barratt <[hidden email]>
> wrote:
> >
> > A customer, by definition (https://en.wikipedia.org/wiki/Customer)
> > exchanges something of value (money) for a product or service.
> >
> > That does not mean that a freemium model (
> > https://en.wikipedia.org/wiki/Freemium) is not a valid business model.
> > However, if there is no exchange of value, the person consuming the free
> > version of the product or service, is not (yet) a customer.
> >
> > If MediaWiki is the thing we give away for free, what do we charge money
> > for?
> > Are our customers successfully subsidizing our free (as in beer)
> software?
> >
> > On Mon, Mar 11, 2019 at 7:33 PM John Erling Blad <[hidden email]>
> wrote:
> >
> > > > 2- Everything is open-source and as non-profit, there's always
> resource
> > > > constraint. If it's really important to you, feel free to make a
> patch
> > > and
> > > > the team would be always more than happy to review.
> > >
> > > Wikipedia is the core product, and the users are the primary
> > > customers. When a group of core customers request a change, then the
> > > service provider should respond. Whether the service provider is a
> > > non-profit doesn't really matter, the business model is not part of
> > > the functional requirement. The service provider should simply make
> > > sure the processes function properly.
> > >
> > > If the service provider has resource constraints, then it must scale
> > > the services until it gets a reasonable balance, but that does not
> > > seem to be the case here. It is more like there are no process or the
> > > process is defunc.
> > >
> > > The strange thing is; for many projects the primary customers aren't
> > > even part of a stakeholder group, the devs in the groups defines
> > > themselves as the "product user group". That tend to skew development
> > > from bugs to features. Perhaps that is what happen in general here,
> > > too much techies that believe they are the primary customers.
> > >
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > [hidden email]
> > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > _______________________________________________
> > Wikitech-l mailing list
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Pine W
I'm going to make a few points that I think will respond to some comments
that I've read, and I will try to organize some of my previous points so
that they're easier to follow.

1. My impression is that there's agreement that there is a huge backlog.

2. I think that there's consensus that the backlog is a problem.

3. I think that we're collectively unsure how to address the backlog, or
how to analyze the backlog so that everyone has shared situational
awareness, but we collectively seem to agree that the backlog should be
addressed.

If any of the above is wrong, please feel free to say so.

Regarding my own opinions only, I personally am frustrated regarding
multiple issues:

a. that there's been discussion for years about technical debt,

b. that WMF's payroll continues to grow, and while I think that more
features are getting developed, the backlog seems to be continuing to grow,

c. that WMF, which has the largest budget of any Wikimedia entity, is not
more transparent regarding how it spends money and what is obtained from
that spending;

d. that although I think that the Community Liaisons help a lot with
communications, there remains much room for improvement of communications.
One of my larger frustrations is that the improvements regarding
communications have not been more extensive throughout all of WMF.

e. that WMF retains the ability to veto community decisions regarding
decisions such as deployments of features, but the community has little
ability to veto WMF decisions. I think that staff as individuals and
collectively have become more willing to negotiate and yield ground in the
past few years, which is good, but I remain concerned that these are
informal rather than formal changes.

f. that I think that some of what WMF does is good and I want to support
those activities, but there are other actions and inactions of WMF that I
don't understand or with which I disagree. Conflicts can be time consuming
and frustrating for me personally, and my guess is that others might feel
the same, including some people in WMF. I don't know how to solve this. I
realize that some people might say "Then you should leave", and I regularly
consider that option, but Wikipedia and the sister projects do a lot of
good, so I'm torn. This is very much my personal issue and I don't expect
to discuss it more on Wikitech-l, but it's a factor in how I think about
this email thread, which is why I mention it.

I hope that this email provides some clarity and is useful for this
discussion.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

David Barratt
>
> I think that there's consensus that the backlog is a problem.
>

For whom is the backlog a problem?

On Tue, Mar 12, 2019 at 4:36 PM Pine W <[hidden email]> wrote:

> I'm going to make a few points that I think will respond to some comments
> that I've read, and I will try to organize some of my previous points so
> that they're easier to follow.
>
> 1. My impression is that there's agreement that there is a huge backlog.
>
> 2. I think that there's consensus that the backlog is a problem.
>
> 3. I think that we're collectively unsure how to address the backlog, or
> how to analyze the backlog so that everyone has shared situational
> awareness, but we collectively seem to agree that the backlog should be
> addressed.
>
> If any of the above is wrong, please feel free to say so.
>
> Regarding my own opinions only, I personally am frustrated regarding
> multiple issues:
>
> a. that there's been discussion for years about technical debt,
>
> b. that WMF's payroll continues to grow, and while I think that more
> features are getting developed, the backlog seems to be continuing to grow,
>
> c. that WMF, which has the largest budget of any Wikimedia entity, is not
> more transparent regarding how it spends money and what is obtained from
> that spending;
>
> d. that although I think that the Community Liaisons help a lot with
> communications, there remains much room for improvement of communications.
> One of my larger frustrations is that the improvements regarding
> communications have not been more extensive throughout all of WMF.
>
> e. that WMF retains the ability to veto community decisions regarding
> decisions such as deployments of features, but the community has little
> ability to veto WMF decisions. I think that staff as individuals and
> collectively have become more willing to negotiate and yield ground in the
> past few years, which is good, but I remain concerned that these are
> informal rather than formal changes.
>
> f. that I think that some of what WMF does is good and I want to support
> those activities, but there are other actions and inactions of WMF that I
> don't understand or with which I disagree. Conflicts can be time consuming
> and frustrating for me personally, and my guess is that others might feel
> the same, including some people in WMF. I don't know how to solve this. I
> realize that some people might say "Then you should leave", and I regularly
> consider that option, but Wikipedia and the sister projects do a lot of
> good, so I'm torn. This is very much my personal issue and I don't expect
> to discuss it more on Wikitech-l, but it's a factor in how I think about
> this email thread, which is why I mention it.
>
> I hope that this email provides some clarity and is useful for this
> discussion.
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Andre Klapper-2
In reply to this post by Pine W
On Tue, 2019-03-12 at 20:34 +0000, Pine W wrote:
>
> 1. My impression is that there's agreement that there is a huge backlog.

Phabricator is public. Anyone can propose and report anything. Hence
the number of ideas, bugs, feature requests is usually higher than the
number of available developers (paid or not) needed to work on them.
Hence the number of tasks which will remain unresolved grows.
Because in theory someone could always show up and provide a patch.

If you know a larger free and open source software project where the
number of resolved (not: declined) tickets per month/year/etc is higher
than the number of open(ed) tickets, I'd be curious to know.

> 2. I think that there's consensus that the backlog is a problem.

No, why?

There are likely quite some ideas that don't make much sense to
prioritize and fix (out of project scope, time consuming because of
required huge architecture changes, increased test complexity and
maintenance costs after adding yet another preference, etc etc).

And many ideas and bugs that will not get fixed (limited number of
available developers, different individual and group priorities) until
you (or someone else) writes code if you're really interested in seeing
that fixed. (If that idea is considered 'in scope' - see above.)

And disappointment *if* someone makes a decision to decline a request.
And followup discussion to challenge someone's decision which takes
time that could have been spent to work on tasks that someone considers
more important.
In practice, people and time are limited resources.

andre
--
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Bartosz Dziewoński
In reply to this post by Pine W
I get an impression from this thread that the problem is not really the
size of the backlog, but rather certain individual tasks that sit in
said backlog rather than being worked on, and which according to John
are actually major issues.

It's hard to disagree or agree with this without knowing which tasks it
is actually about though.

--
Bartosz Dziewoński

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Pine W
In reply to this post by Andre Klapper-2
Andre, good points, thanks. I think that this ties in with my comments
regarding having a common situational awareness. I don't think that I have
good situational awareness regarding the state of the backlog, the
composition of the backlog, etc. I'm confident that there is a backlog and
that there are tasks in that backlog which I would like to see solved, but
it's difficult to get a sense of the big picture.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )


On Tue, Mar 12, 2019 at 9:13 PM Andre Klapper <[hidden email]>
wrote:

> On Tue, 2019-03-12 at 20:34 +0000, Pine W wrote:
> >
> > 1. My impression is that there's agreement that there is a huge backlog.
>
> Phabricator is public. Anyone can propose and report anything. Hence
> the number of ideas, bugs, feature requests is usually higher than the
> number of available developers (paid or not) needed to work on them.
> Hence the number of tasks which will remain unresolved grows.
> Because in theory someone could always show up and provide a patch.
>
> If you know a larger free and open source software project where the
> number of resolved (not: declined) tickets per month/year/etc is higher
> than the number of open(ed) tickets, I'd be curious to know.
>
> > 2. I think that there's consensus that the backlog is a problem.
>
> No, why?
>
> There are likely quite some ideas that don't make much sense to
> prioritize and fix (out of project scope, time consuming because of
> required huge architecture changes, increased test complexity and
> maintenance costs after adding yet another preference, etc etc).
>
> And many ideas and bugs that will not get fixed (limited number of
> available developers, different individual and group priorities) until
> you (or someone else) writes code if you're really interested in seeing
> that fixed. (If that idea is considered 'in scope' - see above.)
>
> And disappointment *if* someone makes a decision to decline a request.
> And followup discussion to challenge someone's decision which takes
> time that could have been spent to work on tasks that someone considers
> more important.
> In practice, people and time are limited resources.
>
> andre
> --
> Andre Klapper | Bugwrangler / Developer Advocate
> https://blogs.gnome.org/aklapper/
>
>
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Stas Malyshev
In reply to this post by Pine W
Hi!


> 1. My impression is that there's agreement that there is a huge backlog.

Obviously, there is a backlog. As for it being "huge", it's subjective,
for someone who has experience with long-running projects, having
thousands of issues in the bug tracker is nothing out of the ordinary.
Does it make the backlog "huge"? I don't know, depends of what is "huge".

> 2. I think that there's consensus that the backlog is a problem.

I'm not sure where such a consensus came from. Of course, bugs not being
resolved immediately is not the ideal situation - ideally, the bug would
be fixed within hours of submitting it. Nobody thinks it can really
happen. Any large popular long-running project has more bugs and
wishlist items than it can implement. There are always more users than
developers and more ideas than time. Thus, the backlog. Of course,
ignoring the backlog completely would be the problem, but I don't think
we have this situation. It's likely we could do better. But I think we
know the backlog exists, and its existence by itself is not a problem,
or at least not a problem that can be realistically solved for such a
huge project.

> Regarding my own opinions only, I personally am frustrated regarding
> multiple issues:
>
> a. that there's been discussion for years about technical debt,

I'm not sure why it's the source of frustration for you. Having
discussion about technical debt is great. Of course, it should also lead
to fixing the said debt - which I think is happening. But expecting that
starting some magic date we stop having technical debt or the need to
address it as realistic as deciding starting today our code won't have
bugs anymore.

> b. that WMF's payroll continues to grow, and while I think that more
> features are getting developed, the backlog seems to be continuing to grow,

Of course. How it could be any other way? With more features, come more
places that can have bugs (you don't expect WMF to be the only software
developing organization in the Multiverse that writes code without
bugs?) and once people start using them, they inevitably ask for
improvements and have ideas on how to extend it, thus adding more tasks.
Expecting that more functionality would lead to less issues in the bug
tracker is contrary to what I have experienced over my whole career - it
never happened, unless the project is effectively dead and the users
have moved away.

> f. that I think that some of what WMF does is good and I want to support
> those activities, but there are other actions and inactions of WMF that I
> don't understand or with which I disagree. Conflicts can be time consuming> and frustrating for me personally, and my guess is that others might feel
> the same, including some people in WMF. I don't know how to solve this. I

I don't think it's possible to "solve" this. Unless you are appointed
the Supreme Dictator of WMF, there always would be things that WMF does
and you disagree. And so would be the case for every other person who
cares about what WMF does. We just need to find things that we can do
that a lot of people can use and not too many people disagree, but
there's no way to guarantee you won't disagree with anything (for any
value of "you"). I think we already have processes for finding this kind
of kinda-consensus-even-though-not-completely. As all processes, they
are not ideal. They can be improved with specific suggestions. But
expecting that nobody (and any specific person in particular) would ever
think "WMF is totally wrong in doing this!" is not realistic. Reasonable
people can and do disagree. Reasonable people also can work through
disagreements and find common interests and ways to contribute to mutual
benefit. I think that's what we're trying to do here.

--
Stas Malyshev
[hidden email]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

John Erling Blad
In reply to this post by Bartosz Dziewoński
On Tue, Mar 12, 2019 at 10:29 PM Bartosz Dziewoński <[hidden email]> wrote:
>
> I get an impression from this thread that the problem is not really the
> size of the backlog, but rather certain individual tasks that sit in
> said backlog rather than being worked on, and which according to John
> are actually major issues.

Sorry, but what I said initially was "bugs with know fixes and
available patches". It could be some "major issues", but I have not
referred to any one, and I'm not sure it is wise to start discussing
specific issues.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

John Erling Blad
In reply to this post by Pine W
What frustrates me the most are

- bugs found by the editor community, that has obvious simple fixes,
which isn't acted upon for several years
- new features that isn't fully tested, and you have to answer in the
community about stuff you rather want to throw out
- new features and changes that are advertised but never implemented

The first one is perhaps the one most easily fixed. I believe WMF
could set up either an official bug squad, or use bug bounties to
speed up fixing of bugs. I tend to believe bug bounties works best,
but it would be really nice to know that bugs are handled in an
orderly fashion by a bug squad.

When introducing new features make a help page at Meta or Mediawiki,
and link to the page from the feature. On that page make a visible
link "Don't panic!" and link to the issue tracker. Don't expect the
users to figure out which extension provides the specific feature,
they don't have a clue. For all important issues make an estimated fix
time, and if no one works on the issue say so. Don't assume the users
understand fancy wording about "need volunteer". Need volunteer for
what? Making coffee?

Some features are described in Phabricator, which is fine, but some of
them has extensive cookie licking which could give someone the
impression that you actually will implement the feature. That often
leads to users asking about the feature, and when it will arrive at
their project. When it does not arrive users gets upset. If you are
working on something, say it, but also be very clear if something has
gone into you personal freezer.


On Tue, Mar 12, 2019 at 9:35 PM Pine W <[hidden email]> wrote:

>
> I'm going to make a few points that I think will respond to some comments
> that I've read, and I will try to organize some of my previous points so
> that they're easier to follow.
>
> 1. My impression is that there's agreement that there is a huge backlog.
>
> 2. I think that there's consensus that the backlog is a problem.
>
> 3. I think that we're collectively unsure how to address the backlog, or
> how to analyze the backlog so that everyone has shared situational
> awareness, but we collectively seem to agree that the backlog should be
> addressed.
>
> If any of the above is wrong, please feel free to say so.
>
> Regarding my own opinions only, I personally am frustrated regarding
> multiple issues:
>
> a. that there's been discussion for years about technical debt,
>
> b. that WMF's payroll continues to grow, and while I think that more
> features are getting developed, the backlog seems to be continuing to grow,
>
> c. that WMF, which has the largest budget of any Wikimedia entity, is not
> more transparent regarding how it spends money and what is obtained from
> that spending;
>
> d. that although I think that the Community Liaisons help a lot with
> communications, there remains much room for improvement of communications.
> One of my larger frustrations is that the improvements regarding
> communications have not been more extensive throughout all of WMF.
>
> e. that WMF retains the ability to veto community decisions regarding
> decisions such as deployments of features, but the community has little
> ability to veto WMF decisions. I think that staff as individuals and
> collectively have become more willing to negotiate and yield ground in the
> past few years, which is good, but I remain concerned that these are
> informal rather than formal changes.
>
> f. that I think that some of what WMF does is good and I want to support
> those activities, but there are other actions and inactions of WMF that I
> don't understand or with which I disagree. Conflicts can be time consuming
> and frustrating for me personally, and my guess is that others might feel
> the same, including some people in WMF. I don't know how to solve this. I
> realize that some people might say "Then you should leave", and I regularly
> consider that option, but Wikipedia and the sister projects do a lot of
> good, so I'm torn. This is very much my personal issue and I don't expect
> to discuss it more on Wikitech-l, but it's a factor in how I think about
> this email thread, which is why I mention it.
>
> I hope that this email provides some clarity and is useful for this
> discussion.
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Andre Klapper-2
In reply to this post by John Erling Blad
On Fri, 2019-03-08 at 13:31 +0100, John Erling Blad wrote:
> The backlog for bugs are pretty large (that is an understatement),
> even for bugs with know fixes and available patches

On tickets in general (not: patches) and their prioritization, I wrote
https://www.mediawiki.org/wiki/Bug_management/Development_prioritization
to answer "Why has nobody fixed this yet?", "Why wasn't I consulted
about these changes?" and "How I can influence what is worked on?".

Cheers,
andre
--
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

John Erling Blad
This is like an enormous sinkhole, with people standing on the edge,
warning about the sinkhole. All around people are saying "we must do
something"! Still the sinkhole slowly grows larger and larger. People
placing warning signs "Sinkhole ahead". Others notifying neighbors
about the growing sinkhole. But nobody does anything about the
sinkhole itself.

I doubt this will be fixed.

John

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Chico Venancio
John,

Multiple people on this thread have pointed out that you are not giving
specifics bugs that are being ignored by WMF (and should not be). Can you
provide some examples?

Chico Venancio


Em qua, 13 de mar de 2019 às 17:01, John Erling Blad <[hidden email]>
escreveu:

> This is like an enormous sinkhole, with people standing on the edge,
> warning about the sinkhole. All around people are saying "we must do
> something"! Still the sinkhole slowly grows larger and larger. People
> placing warning signs "Sinkhole ahead". Others notifying neighbors
> about the growing sinkhole. But nobody does anything about the
> sinkhole itself.
>
> I doubt this will be fixed.
>
> John
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Strainu
In reply to this post by Victoria Coleman-2
Wow, this thread has become quite huge (which is a good problem to
have!). Trying to repond to a few messages in a single email.

În dum., 10 mar. 2019 la 01:23, Dan Garry (Deskana) <[hidden email]> a scris:
> I'm confused by this. I didn't mention volunteer teams taking over projects
> at all, and I don't think that'd work except in very rare and limited
> circumstances. I was talking about people helping with bug triage on
> Phabricator.

Got it. Glad we agree that project maintenance is the responsibility
of the WMF. :)
Bug triage (and even solving) is a great way of implicating volunteer
developers, the problem is what do you do with bugs on projects where
there are no volunteers. My take is that the paid teams that have
ownership of those products should offer a certain degree of
maintenance at least to widely deployed extensions (i.e. on all
versions of a project). The (negative) example I like to give is
Content Translation, were all bugfixes on v1 were stopped until v2 was
developed, process that was delayed by at least a year if not 2
compared to initial estimates. During this time tech ambassadors were
simply left with the task of explaining to users what they can do to
save their work (hint: nothing). That just shouldn't happen.

> > The projects belong to the community at large, not just the technical
> > subcommunity. They are the ones affected by the  bugs and also they are the
> > ones that need our support. So why should they be ignored in taking this
> > decision?
> >
>
> I'm confused by this too. I wasn't talking about ownership of the Wikimedia
> projects, I was again talking about the bug backlog, which anyone is
> welcome to get involved in simply by registering an account.

Me too. Prioritization should involve (as much as possible, and
certainly more than now) people reporting bugs, regardless of their
ability to provide a patch for the bug they file. If we can go further
into the communities, even better.

>
>
> > My proposal is to begin the discussion here: how can we better relay issues
> > that areSee above - "anyone is welcome" is not enough. more important to communities than new features? How can we have a
> > "community whishlist for bugs"?
> >
>
> The community wishlist explicitly accepts requests to fix bugs, as well
> requests for new features. So, is what you're asking for some process to
> supplement that?

A totally new process is not needed nor desirable. Improvements could
be easily done that would improve the overall results.

The main problem I see with the community wishlist is that it's a
process beside the normal process, not part of it. The dedicated team
takes 10 bugs and other developers another ~10. I think we would be
much better off if each team at the WMF would also take the top ranked
bug on their turf and solve it and bump the priority of all the other
bugs by one (e.g. low->medium). One bug per year per team means at
least 18 bugs (at least if [1] is up to date) or something similar.

As a side note, even this process has degraded over time: check out
how empty is the list for 2017 [2] compared to 2016. [3]

[1] https://meta.wikimedia.org/wiki/Template:Wikimedia_Foundation_departments
[2] https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2017/Results
[3] https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2016/Results

În dum., 10 mar. 2019 la 07:42, Victoria Stavridou-Coleman
<[hidden email]> a scris:
>
> Re reading this now on the ground in Austin, reminds me not to send emails in a hurry from an airplane! So trying again - hopefully more grammatically sound this time!
>
> The Tech Engagement team (which includes Wikimedia Cloud Services) in the Tech department is investing in a developer advocacy team who I hope will (amongst other things) speak on behalf of the communities that are affected by tech debt.

That should help, as long as they speak within the normal development
process and not in parallel. Looking forward to seeing the official
announcement.

În dum., 10 mar. 2019 la 02:28, bawolff <[hidden email]> a scris:

>
> Regarding:
> >My proposal is to begin the discussion here: how can we better relay issues
> >that are more important to communities than new features? How can we have a
> >"community whishlist for bugs"?
>
> Well fundamentally it starts with making a list.
>
> Change happens when stuff is measurable, and people can work towards a
> goal. Failing that, change happens when people can be held accountable.
> Objective measures are needed.

What a wonderful world that would be! Unfortunately, all too often I
feel that objective measures (such as "+1" on bugs, duplicates etc.)
have no effect on prioritization.

> if you for example knew how
> much time WMF currently spends on bug fixing, and you have an idea of how
> much time you think they should be spending. Even if management doesn't
> agree with your proposal, it would at least be specific enough to debate.

I have no way of finding that, do I? If there is one, I would be very
curious to learn of it.

În lun., 11 mar. 2019 la 16:58, Bartosz Dziewoński
<[hidden email]> a scris:
> In my experience WMF teams usually have a way to distinguish "bugs we're
> going to work on soon" and "bugs we're not planning to work on, but we'd
> accept patches". This is usually public in Phabricator, but not really
> documented.

Yes, and also not uniform between teams and prone to change on each
team reorg. Having a list would would be great, but I'm not sure how
maintainable it is. Would you like to start one? ;)

În mar., 12 mar. 2019 la 01:29, John Erling Blad <[hidden email]> a scris:
>
> It seems like some projects simply put everything coming from external
> sources into deep freezer or add "need volunteer". If they respond at
> all. In some cases it could be that the projects are defunc.

No deployed project should be considered defunct. But I agree with
others - naming them would help. Let me start:
- ContentTranslation v1 (obsolete now, has been unmaintained for 2
years while in production)
- UploadWizard (2 with high priority, 40 with normal, a few dozens
low, hundreds more untriaged): this is the project that got us out of
the "overloading the lang parameter for customizing the uploader" era,
the project that is used by millions of people every year, including
during every photo contest

I encourage you all to add more examples.

Thanks to all who chimed in on the subject.
Strainu

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Andre Klapper-2
In reply to this post by John Erling Blad
On Wed, 2019-03-13 at 21:01 +0100, John Erling Blad wrote:
> This is like an enormous sinkhole, with people standing on the edge,
> warning about the sinkhole. All around people are saying "we must do
> something"! Still the sinkhole slowly grows larger and larger. People
> placing warning signs "Sinkhole ahead". Others notifying neighbors
> about the growing sinkhole. But nobody does anything about the
> sinkhole itself.

And repeating the same thing over and over again while repeatedly
ignoring requests to be more specific won't help either...

andre
--
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Question to WMF: Backlog on bugs

Amir Sarabadani-2
In reply to this post by Strainu
On Wed, Mar 13, 2019 at 11:02 PM Strainu <[hidden email]> wrote:

> - ContentTranslation v1 (obsolete now, has been unmaintained for 2
> years while in production)
> - UploadWizard (2 with high priority, 40 with normal, a few dozens
> low, hundreds more untriaged): this is the project that got us out of
> the "overloading the lang parameter for customizing the uploader" era,
> the project that is used by millions of people every year, including
> during every photo contest
>
There's something called code stewardship [0] and there is a process called
code stewardship review for projects that are under-, un- or unclear
maintained [1] which basically a piece of code either gets undeployed from
WMF infra or we find maintainer(s) to fix the bugs. You can find the list
of current and past reviews in [2].

If you think a project doesn't have enough maintainer, you can start the
review process. If there's an active maintainer [3] but they are not fixing
bugs, most importantly critical bugs, you can raise the issue probably here
but with **concrete examples.**

[0]: https://www.mediawiki.org/wiki/Code_Stewardship
[1]: https://www.mediawiki.org/wiki/Code_stewardship_reviews
[2]: https://phabricator.wikimedia.org/project/board/3144/query/all/
[3]: https://www.mediawiki.org/wiki/Developers/Maintainers
--
Amir
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12345