Re: [Wikitech-l] Question to WMF: Backlog on bugs
Hi! > Yes, there should always be a response to all bugs. Without a response > the impression in the reporting wiki-community would be "nobody cares > about our bug reports". Would a canned "thank you for your feedback, please stay on the line, your call is very important to us" response make anybody feel better? The reality of a project with huge userbase and limited resources is that there are more bugs that can be addressed seriously and substantially, not with a canned response that does not solve the issue, than there's developer resource. It doesn't mean "nobody cares about the bug reports" - it means some bug reports will be cared for first and some later (and possibly some, unfortunately, never). This set of priorities can be influenced by alerting developer's attention about specific bugs needing addressing, and by existing prioritisation processes, which very much include community input, but the harsh reality of having a lot of bugs dictates that giving serious non-canned attention leading to satisfactory outcome to 100% of them is IMHO not realistic. We could of course institute the policy of "every bug should have a comment from a developer within X time" - but unless X is very large, I think it will be unsatisfactory, since getting "yes, it's a very important bug, thanks for submitting it" comment without the bug being fixed is IMHO no better than getting no comment at all. -- 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
On Wed, 2019-03-13 at 01:22 +0100, John Erling Blad wrote:
> 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
Could you please provide a specific example (link) for the last item?
> The first one is perhaps the one most easily fixed. I believe WMF
> could set up either an official bug squad
In my understanding a bug squad does not write patches but triages
tickets. Maybe you meant a patchsquad or Gerrit wrangler (in case you
refer to *existing* simple fixes, which is not clear from your words).
Not sure why there is call to some authority ("WMF") here.
> 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.
See https://phabricator.wikimedia.org/T88265#1870218 for risks and
(dis)advantages of bug bounties.
Note that throwing more 'external' developers onto code does not
necessarily "speed up fixing of bugs". Often to the contrary.
> When introducing new features make a help page at Meta or Mediawiki,
> and link to the page from the feature.
Looking at the beta features section at
https://meta.wikimedia.org/wiki/Special:Preferences#mw-prefsection-betafeatures
all beta features have "Discussion" and "Information" links.
What you are suggesting already happens.
> 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.
When nobody works on an issue, Phabricator's "Assigned To" field
usually shows "None". What you are suggesting already happens.
Cookie licking can happen though (means: someone assigns a ticket to
themselves and then does not work on it). It's up to each assignee to
occasionally check which tasks are (still) assigned to them:
https://phabricator.wikimedia.org/maniphest/query/5INV_avtCreJ/#R
> 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.
Could you please provide a specific example (link) for this?
> 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.
Cheers,
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
On Wed, Mar 13, 2019 at 3:02 PM Strainu wrote: > 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. > Community Tech is seven people and they do ten wishlist requests a year. (Granted, they do other things too, but the wishlist is their main focus.) So you are proposing to reallocate on average 1-2 months per year for every team to work on wishlist wishes. That's about two million dollars of donor money. How confident are you that the wishlist is actually a good way of estimating the impact of tasks, outside of the narrow field where editors have personal experience (ie. editing tools)? 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. > Leaving aside how objective those measures are, in my when the task is related to a product owned by a team, they are aware and take it into account. (Which does not necessarily mean they agree, of course.) A lot of production components don't really have an owner, though. (Or only do to the extent that there is someone who can be pulled away from their normal job if the thing catches fire.) That's just the reality of running the website we have with the capacity we have - the alternative would be undeploying things or not starting new projects for a long time. The Wikimedia movement happens to be in the middle of its strategic planning process, so if you want to argue for either of these things, this is a good time to do it. (Not a good place, though.) - 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 > UploadWizard is not in active development currently. If you want to argue that the Multimedia team should be reassigned to work on it (and drop the Structured Data on Commons project), or some other rearrangement should be made, that's a specific proposal that can be meaningfully discussed. (Probably not here, though - that's a matter of movement strategy, not a technical decision. So maybe better suited to wikimedia-l.) Saying that some project should be picked up, without saying what should be dropped to make space, is an easy thing to do. Not all that useful though. (As an aside, I'd love to see more people self-organize to get more say in how priorities are decided. If you look at the discussion pages on WMF annual plans, movement strategy and so on, they do not give the impression of a community that's seriously interested in its own future.) ___ 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
On Thu, Mar 14, 2019 at 4:36 AM John Erling Blad wrote: > Google had a problem with unfixed bugs, and they started identifying > the involved developers each time the build was broken. That is pretty > harsh, but what if devs somehow was named when their bugs were > mentioned? What if there were some kind of public statistic? How would > the devs react to being identified with a bug? Would they fix the bug, > or just be mad about it? Devs at some of Googles teams got mad, but in > the end the code were fixed. Take a look at "GTAC 2013 Keynote: > Evolution from Quality Assurance to Test Engineering" [1] > Sorry to be direct but you seem to have little understanding of what you are talking about. You are equivocating different things and shifting goalposts every time you comment on this thread. You are jumping between various positions involving "a large bug backlog is bad", "important bugs are not getting prioritized accordingly", "the WMF should scale its services down so it has the capacity to respond to every request" (ie. fire some developers, hire more community liasions), and now you are talking about broken builds. Every time someone challenges your claims, you just switch to talking about another one. This is frustrating and a waste of other people's time. Please try to pin down what you are trying to propose before making the proposal. For those unfamiliar with development processes, a broken build means the application is not starting at all, which means other developers cannot test their own work, which means the entire development process grinds to a halt. That is a huge hit to productivity so software organizations usually try hard to avoid it, even though it's an internal issue with no user impact (well, other than the organization shipping less features / fixes in the next release because developer time was spent less effectively). The closest equivalent we have for that is continuous integration tests broken by merged code (although that's less severe since it usually doesn't stop the application from working). While I'm sure the handling of those could be improved (incidentally, that's just happening, see https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/CI_Futures_WG ), it has nothing to do with the original topic of this thread, since it is happening in the development cycle and not visible to users. About backlogs in general, Chromium is probably the biggest open-source Google repo; that has currently 940K tickets, 60K of which are open, and another 50K have been auto-archived after a year of inactivity. (As others have pointed out, having a huge backlog and ruthlessly closing tasks that do not get on the roadmap are the only two realistic options, and the latter does have its advantages, no one here seems to be in favor of it.) We have 220K tasks in total, 40K of which are open, so that's in the same ballpark (not that that comparing open task ratios is particularly meaningful - but it hopefully shows that Google's handling of the completely unrelated build breaking issue does not magically make them have zero bugs). What if we could show information from the bugs in Phabricator in a > "tracked" template at other wiki-projects, identifying the team > responsible and perhaps even the dev assigned to the bug? Users who are interested in that information would be spared the enormous effort of pressing a button on the mouse, I guess? > We say we don't want voting over bugs, but by saying that we refuse > getting stats over how many users a specific bug hits, and because of > that we don't get sufficient information (metrics) to make decisions > about specific bugs. Some bugs (or missing features) although changes > how users are doing specific things, how do we handle that? > How many people vote on a bug and how many people are hit by a bug are two entirely different things, and most of the time it's hard to measure the latter. Voting will be dominated by power users who are more engaged with the development process, users who understand English, users who come from a larger wiki community and can canvass better, etc. (And Phabricator doesn't support voting anyway.) > What if users could give a "this hits me too" from a "tracked" > template. That would give a very simple metric on how important it is > to fix a problem. To make this visible to the wiki-communities the > special page could be sorted on this metric. Of course the devs would > have completely different priorities, but this page would list the > wiki-communities priorities. > Having a page which lists the priorities of wiki communities (more realistically, one specific wiki community) would be very useful, IMO. As others have pointed out, the reason no such list exists is that people are spending their time complaining here, instead of building lists on their wiki. (At which point they would quickly find out that actually getting a consensus on priorities is a lot harder than complaining about wh
Re: [Wikitech-l] Unbreak now! problem in this week train Watchlist
I ment, when you open the unread page, it is marked as read. Igal בתאריך יום ה׳, 14 במרץ 2019 ב-19:37 מאת Brad Jorsch (Anomie) < bjor...@wikimedia.org>: > On Thu, Mar 14, 2019 at 1:29 PM יגאל חיטרון > wrote: > > > From time to time the API post query "mark this revision as read" does > not > > work. > > > Nothing in the reproduction steps you list does such a post query. > > -- > 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Unbreak now! problem in this week train Watchlist
This sounds like it could have been caused by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/416198 On Thu, Mar 14, 2019 at 10:29 AM יגאל חיטרון wrote: > Hello. There is a regression problem, that started on this week deployment. > I can see it in group 1 from yesterday evening. I do not file a phabricator > ticket, because there is no algorithm to reproduce the problem. > > From time to time the API post query "mark this revision as read" does not > work. In these times, there is a reproducing algorithm: > 1) Open Special:Watchlist. > 2) Pick an unread revision. > 3) Open the diff to last version, or the view mode of the page. > 4) Expected: the revision, and the whole page, should be automatically > marked as read. > 5) Refresh the Special:Watchlist. > 6) Got: the revision remains bold. > 7) Open API query for unread revisions, the relevant one is still there. > 8) Try partagraphs 5-7 every 5 seconds. > 9) In about twenty minutes the data is updated correctly. > I saw this yesterday at about 19:45 UTC, and it happens again just now. > Thank you. > Igal (User:IKhitron) > ___ > 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] Unbreak now! problem in this week train Watchlist
On Thu, Mar 14, 2019 at 1:29 PM יגאל חיטרון wrote: > From time to time the API post query "mark this revision as read" does not > work. Nothing in the reproduction steps you list does such a post query. -- 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
[Wikitech-l] Unbreak now! problem in this week train Watchlist
Hello. There is a regression problem, that started on this week deployment. I can see it in group 1 from yesterday evening. I do not file a phabricator ticket, because there is no algorithm to reproduce the problem. From time to time the API post query "mark this revision as read" does not work. In these times, there is a reproducing algorithm: 1) Open Special:Watchlist. 2) Pick an unread revision. 3) Open the diff to last version, or the view mode of the page. 4) Expected: the revision, and the whole page, should be automatically marked as read. 5) Refresh the Special:Watchlist. 6) Got: the revision remains bold. 7) Open API query for unread revisions, the relevant one is still there. 8) Try partagraphs 5-7 every 5 seconds. 9) In about twenty minutes the data is updated correctly. I saw this yesterday at about 19:45 UTC, and it happens again just now. Thank you. Igal (User:IKhitron) ___ 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
On Thu, 2019-03-14 at 15:50 +0100, John Erling Blad wrote: > Yes, there should always be a response to all bugs. Without a response > the impression in the reporting wiki-community would be "nobody cares > about our bug reports". > > Someone in the community finds a bug, and it is posted and discussed > in the community. Then another one writes a report in a task at > Phabricator, but nothing further happen. A couple of months later the > first one ask again about the bug, but does not get a satisfactory > answer, and gets angry. This usually happen in cycles of a few months > to a year. We must somehow break those cycles, they are bad and > disruptive and creates a "us and them" attitude. I've seen it a few times on wiki village pumps or wiki article talk pages that someone points out something and then nobody else replied (or "nobody cared", as you call it). And then people "get angry" as you call it. Do you manage to reply to all and each post in your local wiki community, or how do you deal with this problem? 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
‐‐‐ Original Message ‐‐‐ On Thursday, March 14, 2019 3:56 PM, David Barratt wrote: > Is the Wikimedia Foundation responsible for people's emotions? Yes. Frustration, mostly. It is not entirely unexpected that this message originates from @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
Is the Wikimedia Foundation responsible for people's emotions? On Thu, Mar 14, 2019 at 10:51 AM John Erling Blad wrote: > Yes, there should always be a response to all bugs. Without a response > the impression in the reporting wiki-community would be "nobody cares > about our bug reports". > > Someone in the community finds a bug, and it is posted and discussed > in the community. Then another one writes a report in a task at > Phabricator, but nothing further happen. A couple of months later the > first one ask again about the bug, but does not get a satisfactory > answer, and gets angry. This usually happen in cycles of a few months > to a year. We must somehow break those cycles, they are bad and > disruptive and creates a "us and them" attitude. > > Users from the wiki-communities don't visit Phabricator to see all > those small administrative tasks, they see the notes from the official > and unofficial tech ambassadors, and they see the changes in the > "tracked" templates. The templates are only changed when the bugs are > closed for whatever reason, which could take years. Creating > additional manual interventions does not work, the process must be > simpler and more efficient. > > On Thu, Mar 14, 2019 at 1:23 PM Andre Klapper > wrote: > > > > On Tue, 2019-03-12 at 00:29 +0100, John Erling Blad wrote: > > > 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. > > > > What's the expectation based on that there should always be a response? > > If a bug report has all info needed to allow someone to reproduce and > > work on it, anyone is free to pick it up and work on it if anyone is > > interested in working on it. No further response needed. > > > > Cheers, > > 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 ___ 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
Yes, there should always be a response to all bugs. Without a response the impression in the reporting wiki-community would be "nobody cares about our bug reports". Someone in the community finds a bug, and it is posted and discussed in the community. Then another one writes a report in a task at Phabricator, but nothing further happen. A couple of months later the first one ask again about the bug, but does not get a satisfactory answer, and gets angry. This usually happen in cycles of a few months to a year. We must somehow break those cycles, they are bad and disruptive and creates a "us and them" attitude. Users from the wiki-communities don't visit Phabricator to see all those small administrative tasks, they see the notes from the official and unofficial tech ambassadors, and they see the changes in the "tracked" templates. The templates are only changed when the bugs are closed for whatever reason, which could take years. Creating additional manual interventions does not work, the process must be simpler and more efficient. On Thu, Mar 14, 2019 at 1:23 PM Andre Klapper wrote: > > On Tue, 2019-03-12 at 00:29 +0100, John Erling Blad wrote: > > 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. > > What's the expectation based on that there should always be a response? > If a bug report has all info needed to allow someone to reproduce and > work on it, anyone is free to pick it up and work on it if anyone is > interested in working on it. No further response needed. > > Cheers, > 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
[Wikitech-l] OOUI v0.31.0 released – PHP layouts, breaking changes et al
Hello everyone, I'm pleased to announce that we've released OOUI v0.31.0 yesterday. Key highlights of this release: - IndexLayout (tab layout) and all its dependent layouts - StackLayout, - MenuLayout, - TabPanelLayout and TabSelectWidget/TabOptionWidget are all now provided server-side in PHP as well. Thanks to Cormac Parle, the Multimedia team and Ed Sanders for providing those. - Mixin configs are made extendable Config options are always overridable unless explicitly needed to force a value to them. - New 'success' type was added as FieldLayout message type additionally to 'error' and 'warning'. Apart from above, there are also possible breaking changes in this release: Please carefully consider if they affect your code. - Remove FlaggedElement from InputWidget. Only TextInputWidget & ButtonInputWidget use or require flags, so mixin FlaggedElement to those directly. The following classes are no longer flagged: - CheckboxInputWidget - CheckboxMultiselectInputWidget - DropdownInputWidget - RadioSelectInputWidget - Remove method names, like for example `onMouseUp` or `onMouseMove`, which got deprecated in v0.28.3 and replaced by `onDocumentMouseUp` and `onDocumentMouseMove`. - Drop `iconTitle` and `indicatorTitle` properties, deprecated in v0.30.0, use `title` instead. - Drop 'search' indicator, deprecated in v0.30.0, in this release removed completely. This indicator hasn't been used anywhere to our knowledge. 'search' icon is the replacement where needed. You can find details on additional new features, code-level and accessibility changes, styling and interaction design amendments, and all improvements since v0.30.0 in the full changelog[1]. If you have any further queries or need help dealing with breaking changes, please let me know. As always, interactive demos[0] and library documentation is available on mediawiki.org[2], there is comprehensive generated code-level documentation and interactive demos and tutorials hosted on doc.wikimedia.org[3]. OOUI version: 0.31.0 MediaWiki version: 1.33.0-wmf.22 Date of deployment to production: Regular train, starting Tuesday 19 March [0] - https://doc.wikimedia.org/oojs-ui/master/demos/#widgets-mediawiki-vector-ltr [1] - https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/History.md [2] - https://www.mediawiki.org/wiki/OOUI [3] - https://doc.wikimedia.org/oojs-ui/master/ Best, Volker -- Senior UX Engineer 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] Question to WMF: Backlog on bugs
Sorry, but I try to point out that the process is broken and give a
few examples on how to fix the process.
On Thu, Mar 14, 2019 at 1:20 PM Andre Klapper wrote:
>
> On Thu, 2019-03-14 at 12:35 +0100, John Erling Blad wrote:
> > Blame games does not fix faulty processes.
>
> Hmm, why is this thread called "Question to WMF" instead of "Question
> to developers"?
>
> > Why do we have bugs that isn't handled for years?
>
> Basically: Because you did not fix these bugs. Longer version:
> https://www.mediawiki.org/wiki/Bug_management/Development_prioritization
>
> > Why is it easier to get a new feature than fixing an old bug?
>
> {{Citation needed}}.
> If that was the case: Because your priority was to write code for a new
> feature instead of fixing an old bug. Longer version:
> https://www.mediawiki.org/wiki/Bug_management/Development_prioritization
>
> > Google had a problem with unfixed bugs, and they started identifying
> > the involved developers each time the build was broken. That is pretty
> > harsh, but what if devs somehow was named when their bugs were
> > mentioned? What if there were some kind of public statistic? How would
> > the devs react to being identified with a bug? Would they fix the bug,
> > or just be mad about it? Devs at some of Googles teams got mad, but in
> > the end the code were fixed. Take a look at "GTAC 2013 Keynote:
> > Evolution from Quality Assurance to Test Engineering" [1]
>
> Not really - I see 6 open bug reports in Chromium, for example:
> https://bugs.chromium.org/p/chromium/issues/list
> (Only if you want to imply that only "Google" was responsible for
> fixing all bugs in that free and open source project, of course.)
>
> > What if we could show information from the bugs in Phabricator in a
> > "tracked" template at other wiki-projects, identifying the team
> > responsible and perhaps even the dev assigned to the bug? Imagine the
> > creds the dev would get when the bug is fixed! Because it is easy to
> > loose track of pages with "tracked" templates we need some other means
> > to show this information, and our "public monitor" could be a special
> > page with the same information.
>
> Feel free to extend https://www.mediawiki.org/wiki/Template:Tracked
>
> > We say we don't want voting over bugs, but by saying that we refuse
> > getting stats over how many users a specific bug hits, and because of
> > that we don't get sufficient information (metrics) to make decisions
> > about specific bugs.
>
> I disagree. Different people see different priorities. Longer version:
> https://www.mediawiki.org/wiki/Bug_management/Development_prioritization
>
> > What if users could give a "this hits me too" from a "tracked"
> > template. That would give a very simple metric on how important it is
> > to fix a problem.
>
> It does not, because software development is not a popularity contest:
> https://www.mediawiki.org/wiki/Bug_management/Development_prioritization
> Voting would create expectations that nobody will fulfill.
>
> Cheers,
> 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
[Wikitech-l] Commons app update - v2.10, and next steps
Hi all, Version 2.10 of the Commons Android app has just been released to production on the Google Play Store[1] (also downloadable on F-Droid[2]). The update contains: New features: - Users can search for (and upload pictures for) places that need pictures in any location, not just their current location - Current ongoing campaigns, if any, are displayed on the main screen - "Retry" button to easily re-upload failed uploads Fixes: - Optimized Nearby map loading time - Fixed various bugs and crashes, including errors with "image taken" date We're excited to announce that we've also had our recent Project Grant proposal[3] approved. :) This means there will be lots of improvements coming up in 2019, with focus on improving stability and the upload experience for users. Our first priority will be rewriting the legacy backend code to adhere to modern standards and reduce complexity (especially the network layer, which currently uses a deprecated API). This is aimed at resolving a few major lingering bugs (especially upload failures for a few users), as well as creating a solid technical foundation to base future improvements on. Several new features are slated for release after that, including filters and bookmarks for the "Nearby places that needs pictures" feature, a pause and resume function for uploads, and a "limited connection" mode. Thank you so much to everyone who has supported us thus far, especially in the last rocky year! :) At the conclusion of this grant, we hope to deliver a much better app to you. Best regards, Josephine / @misaochan (project maintainer) [1]: https://play.google.com/store/apps/details?id=fr.free.nrw.commons [2]: https://f-droid.org/repository/browse/?fdid=fr.free.nrw.commons [3]: https://meta.wikimedia.org/wiki/Grants:Project/Commons_app/Commons_Android_app_v3 ___ 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
On Tue, 2019-03-12 at 00:29 +0100, John Erling Blad wrote: > 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. What's the expectation based on that there should always be a response? If a bug report has all info needed to allow someone to reproduce and work on it, anyone is free to pick it up and work on it if anyone is interested in working on it. No further response needed. Cheers, 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
On Thu, 2019-03-14 at 12:35 +0100, John Erling Blad wrote:
> Blame games does not fix faulty processes.
Hmm, why is this thread called "Question to WMF" instead of "Question
to developers"?
> Why do we have bugs that isn't handled for years?
Basically: Because you did not fix these bugs. Longer version:
https://www.mediawiki.org/wiki/Bug_management/Development_prioritization
> Why is it easier to get a new feature than fixing an old bug?
{{Citation needed}}.
If that was the case: Because your priority was to write code for a new
feature instead of fixing an old bug. Longer version:
https://www.mediawiki.org/wiki/Bug_management/Development_prioritization
> Google had a problem with unfixed bugs, and they started identifying
> the involved developers each time the build was broken. That is pretty
> harsh, but what if devs somehow was named when their bugs were
> mentioned? What if there were some kind of public statistic? How would
> the devs react to being identified with a bug? Would they fix the bug,
> or just be mad about it? Devs at some of Googles teams got mad, but in
> the end the code were fixed. Take a look at "GTAC 2013 Keynote:
> Evolution from Quality Assurance to Test Engineering" [1]
Not really - I see 6 open bug reports in Chromium, for example:
https://bugs.chromium.org/p/chromium/issues/list
(Only if you want to imply that only "Google" was responsible for
fixing all bugs in that free and open source project, of course.)
> What if we could show information from the bugs in Phabricator in a
> "tracked" template at other wiki-projects, identifying the team
> responsible and perhaps even the dev assigned to the bug? Imagine the
> creds the dev would get when the bug is fixed! Because it is easy to
> loose track of pages with "tracked" templates we need some other means
> to show this information, and our "public monitor" could be a special
> page with the same information.
Feel free to extend https://www.mediawiki.org/wiki/Template:Tracked
> We say we don't want voting over bugs, but by saying that we refuse
> getting stats over how many users a specific bug hits, and because of
> that we don't get sufficient information (metrics) to make decisions
> about specific bugs.
I disagree. Different people see different priorities. Longer version:
https://www.mediawiki.org/wiki/Bug_management/Development_prioritization
> What if users could give a "this hits me too" from a "tracked"
> template. That would give a very simple metric on how important it is
> to fix a problem.
It does not, because software development is not a popularity contest:
https://www.mediawiki.org/wiki/Bug_management/Development_prioritization
Voting would create expectations that nobody will fulfill.
Cheers,
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
Blame games does not fix faulty processes. You fix a sinkhole by figuring out where the water comes from and where it goes. Why do we have bugs that isn't handled for years? Why is it easier to get a new feature than fixing an old bug? Google had a problem with unfixed bugs, and they started identifying the involved developers each time the build was broken. That is pretty harsh, but what if devs somehow was named when their bugs were mentioned? What if there were some kind of public statistic? How would the devs react to being identified with a bug? Would they fix the bug, or just be mad about it? Devs at some of Googles teams got mad, but in the end the code were fixed. Take a look at "GTAC 2013 Keynote: Evolution from Quality Assurance to Test Engineering" [1] What if we could show information from the bugs in Phabricator in a "tracked" template at other wiki-projects, identifying the team responsible and perhaps even the dev assigned to the bug? Imagine the creds the dev would get when the bug is fixed! Because it is easy to loose track of pages with "tracked" templates we need some other means to show this information, and our "public monitor" could be a special page with the same information. We say we don't want voting over bugs, but by saying that we refuse getting stats over how many users a specific bug hits, and because of that we don't get sufficient information (metrics) to make decisions about specific bugs. Some bugs (or missing features) although changes how users are doing specific things, how do we handle that? What if users could give a "this hits me too" from a "tracked" template. That would give a very simple metric on how important it is to fix a problem. To make this visible to the wiki-communities the special page could be sorted on this metric. Of course the devs would have completely different priorities, but this page would list the wiki-communities priorities. It would be a kind of blame game, but it would also give the devs an opportunity to get sainthood by fixing annoying bugs. [1] https://www.youtube.com/watch?v=nyOHJ4GR4iU from 32:20 On Wed, Mar 13, 2019 at 11:49 PM Andre Klapper wrote: > > 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 > 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] Possible change in schedule of generation of wikidata entity dumps
If you use these dumps regularly, please read and weigh in here: https://phabricator.wikimedia.org/T216160 Thanks in advance, Ariel Glenn Wikimedia Foundation ar...@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
În joi, 14 mar. 2019 la 01:02, Amir Sarabadani a scris: > > On Wed, Mar 13, 2019 at 11:02 PM Strainu 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.** I'll rant about UW in a separate thread, right now I just want to mention that [3] presents 3 possible maintainers for it, **none of which did any work on UW in the last 6 months** (and presumably much longer) according to Phab timelines. I know documentation is hard, but this feels a lot like a wild goose chase. Strainu > > [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 > 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] Read access to patrolled flag in wikimedia API
Oh, thanks, it looks usable. As far as i understand this flagged data contains
stable revision for pages, which are have pending changes protection enabled
and when flag is missing means it is disabled, is that correct?
Also is it possible to get all page revisions through this generator, so i can
find stable content or it can only be acomplished with another page revisions
query? When i add prop=revisions
(prop=flagged|revisions&generator=recentchanges) — i get only one latest
revision.
14.03.2019, 08:51, "Max Semenik" :
> I don't think it's possible to filter by flagged status, however you can
> combine this information with recent changes:
> https://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:ApiSandbox#action=query&format=json&prop=flagged&generator=recentchanges&formatversion=2
>
> On Wed, Mar 13, 2019 at 8:52 AM Сибирев Кирилл
> wrote:
>
>> Hi, i can't find information about filtering pending changes through api,
>> can someone
>> help with my previous questions?
>>
>> 06.03.2019, 13:32, "Сибирев Кирилл" :
>> > 05.03.2019, 19:33, "bawolff" :
>> >> Are you sure that patrol status is shown as colour coding on history
>> pages?
>> >> I'm pretty sure its not.
>> >>
>> >> If you mean kind of the dim yellow colour (like in
>> >>
>>
>> https://en.wikipedia.org/w/index.php?title=List_of_programs_broadcast_by_Adult_Swim&action=history
>> >> for the moment, but that will likely change soon), that means a pending
>> >> change, which is a different system from patrolling.
>> >>
>> >> Note, on enwikipedia (but not other projects) RC patrolling is
>> disabled,
>> >> and only new page patrol is enabled (so only the first revision can
>> have a
>> >> patrol status).
>> >
>> > Thanks for the answer, i'm little bit confused by naming here, i guess.
>> > Mostly we use ru.wikipedia.org, where a lot of pages have blue/yellow
>> markup
>> > and legend for blue can be translated as "patrolled version", and yellow
>> is "unverified version"
>> > (here screenshot of what i am talking about
>> https://yadi.sk/i/A0FRG6yz86ECdg)
>> >
>> > So, if i did understand you correctly, blue/yellow markup is about
>> pending changes
>> > (https://en.wikipedia.org/wiki/Wikipedia:Pending_changes) and not
>> patrolling
>> > (https://www.mediawiki.org/wiki/Help:Patrolling), am i right?
>> >
>> > Basically we want to get from api same data which users see on wikipedia
>> article page
>> > and as far as i understand yellow changes are not visible until approved.
>> > Can you send me some page about comparing pending and patrolling,
>> because for now
>> > i can't understand if the two system can be applied to one page and what
>> happens
>> > if revision is patrolled (does it become approved and not pending after
>> that)?
>> >
>> > If pending system is responsible for revision visibility on article page
>> then it is
>> > not matter to us what patrolling does, i guess.
>> > But in that case we need to get pending property of revision from API,
>> is it accessible?
>> >
>> >> --
>> >> Brian
>> >>
>> >> On Tue, Mar 5, 2019 at 4:13 PM Сибирев Кирилл
>> >> wrote:
>> >>
>> >>> Hi, we are using wikimedia http api for getting pages recent changes
>> [1].
>> >>> We'd like to be able to distinguish patrolled and unpatrolled
>> revisions and
>> >>> this feature is supported according to docs, but we still can't use
>> it
>> >>> because of access permissions. For example if i making requests like
>> [2] or
>> >>> [3] i am getting {"code": "permissiondenied", "info": "You need the
>> >>> \"patrol\" or \"patrolmarks\" right to request the patrolled flag."}
>> error.
>> >>>
>> >>> This API behaviour looks inconsistent to me, because anyone can see
>> >>> patrolled/unpatrolled colored markup at wikipedia revision history
>> web
>> >>> pages. I think patrol right should be checked only at write (ones
>> that mark
>> >>> revisions patrolled or not) API requests and not for read requests.
>> >>>
>> >>> Is this behaviour really inconsistent and implemented that way due to
>> >>> technical restrictions or am i missing something? Can it be changed,
>> so we
>> >>> can get patrolling information for revisions or maybe there are some
>> >>> workarounds exist?
>> >>>
>> >>> [1] https://www.mediawiki.org/wiki/API:RecentChanges
>> >>> [2]
>> >>>
>>
>> https://en.wikipedia.org/w/api.php?action=query&list=recentchanges&rcprop=title|patrolled&rclimit=3
>> >>> [3]
>> >>>
>>
>> https://en.wikipedia.org/w/api.php?action=query&list=recentchanges&rcprop=title&rcshow=patrolled&rclimit=3
>> >>>
>> >>> ___
>> >>> 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.or
