Re: [Wikitech-l] Question to WMF: Backlog on bugs

[John Erling Blad]

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  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
> 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] New Gerrit privilege policy

[Tim Starling]

Following approval by TechCom and WMF Interim CTO Erika Bjune, I've
moved the new Gerrit privilege policy page out of my userspace to

https://www.mediawiki.org/wiki/Gerrit/Privilege_policy

This is a merge of two pages: [[Gerrit/+2]] and [[Gerrit/Project
ownership]], with some additional changes. I've now redirected both of
those pages to the new policy page.

The main changes are:

* The wmde LDAP group, representing WMDE staff members, will be given
+2 access to mediawiki/* projects, similar to the rights given to WMF
staff members.

* The ability of ShoutWiki and Hallo Welt! to manage access to the
extensions they maintain is described and formalised.

* The ownership model for extensions is discouraged in favour of
individual requests on Phabricator. An extension owner was able to
promote developers to +2 access at their own discretion.

* The Phabricator projects for requesting access have changed. I'm in
the process of moving the tickets over.

* The revocation policy has been expanded, better describing the
present situation and making several minor changes.

-- Tim Starling


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 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  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  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
> > 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

Re: [Wikitech-l] Community-Engineering gaps as defined in configuration

[James Forrester]

On Sat, 9 Mar 2019 at 11:50, bawolff  wrote:

> In regards to wgUseRCPatrol - I suspect (but don't know) that originally
> that was disabled on enwiki as a performance thing. If it was a performance
> concern, that's probably irrelevant at this point.
>

Sadly, no. It was enabled as a new feature to help communities do their
patrolling work. A small handful on enwiki power users complained in the
hours after it was deployed about the "disruption" (the appearance of a !
on edits in Recent Changes), and rather than help the community adjust to
the new software and find it useful, the feature was disabled, effectively
permanently. In the subsequent years, many English Wikipedians have
complained about the lack of support for their work on Recent Changes
patrolling, but there's been no effort to struggle through the community
arguments to (re-)enable this tool, I believe.

It would be lovely if we could enable this feature on the English Wikipedia
given how useful many other communities have found this, but I don't expect
it to happen.

J.
-- 
*James D. Forrester* (he/him  or they/themself
)
Wikimedia Foundation 
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Improving reading experience on mobile

[Volker E.]

Hi all,
in my part of the Design team at Wikimedia Foundation, I'd like to
share an upcoming change in typography, that might be of interest for
you:

Improving reading experience on mobile [0] –
As many of our projects are putting textual content first, we are
consistently aiming at best possible reading experience for our users,
regardless of the device, software, or language of our readers.
Typography, and specifically font choices, build the base for
readability.
Therefore we have been proposing to rely on so-called system fonts as
our default mobile font choice in the mobile skin MinervaNeue. Both
major platforms, iOS and Android, but also operating systems like
macOS and Windows come out-of-box with better suited system fonts than
the general fallback `sans-serif`. Those specific fonts

 - deliver a better native experience for readers,
 - improve cross-platform and
 - improve cross-language readability.

Please see the project page on mediawiki.org [0] for further technical
details of the changes and an overview of our wide-range testing. Our
current plan is to rollout the change to Beta-Cluster next week.
We welcome your feedback!

Best regards,
Volker

[0] – 
https://www.mediawiki.org/wiki/Design/Projects/Improve_mobile_reading_experience

Senior UX Engineer, UI Standardization Lead (he/him)
Wikimedia Foundation

volke...@wikimedia.org | @Volker_E

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] ManualLogEntries::publish do not store tags when published to `udp`

[Brad Jorsch (Anomie)]

On Mon, Mar 11, 2019 at 9:48 AM Piotr Miazga  wrote:

> I noticed that ManualLogEntry items could have tags only when those
> entries are published to `rc` or `rcandudp`.


Hmm. Yes, it looks like the tags aren't being added in the `udp` case.
Looks like it was broken in
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/312743. Filed T218110
 for that.


> Then the extensions can attach tags via RecentChange_save hook and
> everything works perfectly.


I note this is not really related to the fact that tags set on the
ManualLogEntry aren't stored when entries are published to `udp`, as that
hook doesn't directly deal with log entries at all.

To support tagging published log entries directly rather than via the
associated RecentChange entry, you'd probably want to add a
"ManualLogEntryPublish" hook or something like that.


> Additionally, I'd like to introduce a Taggable interface[6], that provides
> a one way to tag objects (right now RecentChange exposes addTags() method
> but the ManualLogEntry exposes setTags() method).
>

"Taggable" seems like it may be too generic.
"MediaWiki\ChangeTags\Taggable" could work.

-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Pine W]

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 
wrote:

> On Tue, 2019-03-12 at 20:34 +, 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
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Stas Malyshev]

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
smalys...@wikimedia.org

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 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 
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 
> 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 
> 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
> > > 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

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Andre Klapper]

On Tue, 2019-03-12 at 20:34 +, 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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Bartosz Dziewoński]

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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Old tiles.wfmlabs.org maps services need maintainers to keep them alive after december 18th

[Derk-Jan Hartman]

Small update on this.

Over the past 3 months, I have slowly familiarised myself with the
tiles.wmflabs.org and I have now migrated rendering and serving of these
tiles to a new server. I still need to do some work on the following things:

1: tile expiration
2: puppet deployment
3: log collection/rotation
4: renderd logging
5: renderd socket getting stuck ?

wma.wmflabs.org is still not saved however.

DJ

On Wed, Dec 12, 2018 at 2:39 PM Derk-Jan Hartman <
d.j.hartman+wmf...@gmail.com> wrote:

> This is just another small reminder that, because the servers which host
> tiles.wmflabs.org and wma.wmflabs.org (wikiminiatlas)  and overpass-wiki
> run on a version of the OS (Ubuntu Trusty) that is no longer supported
> (and hasn't been available for new instances since november 2017).
>
> These services need maintainers and support by community members in order
> to keep them alive after dec 18th (after which wmflabs will phase out those
> versions) and before the EOL of early 2019 of the OS. Unfortunately it
> seems no one is stepping up so far to convert these machines.
>
> This issue is tracked at https://phabricator.wikimedia.org/T204506
> As I was curious, I looked around on the tile server a bit and used what I
> could find to update
> https://wikitech.wikimedia.org/wiki/OSM_Tileserver#Technology_stack
> This is all the information that I could gather, but i'm FAR from sure if
> that is complete information and if I would break anything with a rebuild
> basing myself on that info, so any information on missing elements etc.
> would be appreciated. I've not gotten around to looking at wikiminiatlas.
>
> If the services are not rebuild then likely they will just disappear at
> some point for all layer variants. This includes the mapnik, black and
> white, hill shading, hike bike layers. As I have no idea how many users of
> these services there are, it is hard to say what the effect of that would
> be.
>
> DJ
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 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  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
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[John Erling Blad]

On Tue, Mar 12, 2019 at 10:29 PM Bartosz Dziewoński  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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Gerrit privilege policy

[Physikerwelt]

On Wed, Mar 13, 2019 at 5:25 AM Tim Starling  wrote:
>
> Following approval by TechCom and WMF Interim CTO Erika Bjune, I've
> moved the new Gerrit privilege policy page out of my userspace to
>
> https://www.mediawiki.org/wiki/Gerrit/Privilege_policy
>
> This is a merge of two pages: [[Gerrit/+2]] and [[Gerrit/Project
> ownership]], with some additional changes. I've now redirected both of
> those pages to the new policy page.
>
> The main changes are:
>
> * The wmde LDAP group, representing WMDE staff members, will be given
> +2 access to mediawiki/* projects, similar to the rights given to WMF
> staff members.

Great. This is the first step towards a global movement;-)

>
> * The ability of ShoutWiki and Hallo Welt! to manage access to the
> extensions they maintain is described and formalised.
>
> * The ownership model for extensions is discouraged in favour of
> individual requests on Phabricator. An extension owner was able to
> promote developers to +2 access at their own discretion.

I think this does not harm too much since many people use Microsofts
GitHub to maintain their non-WMF deployed extensions these days.


Physikerwelt

>
> * The Phabricator projects for requesting access have changed. I'm in
> the process of moving the tickets over.
>
> * The revocation policy has been expanded, better describing the
> present situation and making several minor changes.
>
> -- Tim Starling
>
>
> ___
> 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