[Wikitech-l] MediaWiki 1.26 release blockers
MediaWiki 1.26 will be released later this year. There are 62 open tasks in Phabricator tagged with "MW-1.26-release". Some tasks miss an assignee; some tasks welcome patch review. Dropping some links here to raise awareness and ask for help: 12 without any assignee and without a "Patch-For-Review": https://phabricator.wikimedia.org/maniphest/query/MoC9YKZ4gsR./#R 48 with "Patch-For-Review": https://phabricator.wikimedia.org/maniphest/query/w6gwbg0JIWRl/#R 23 with Assignees set (Aaron, Addshore, Bawolff, bd808, Catrope, Cenarium, Dchan, Gilles, Jdlrobson, Hexmode, Legoktm, Matmarex, Seb35, Sn1per, Tgr, Željko): https://phabricator.wikimedia.org/maniphest/query/KWoEsNbaAjFX/#R andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.26 release blockers
On Thu, Sep 24, 2015 at 10:36 AM, Andre Klapper wrote: > MediaWiki 1.26 will be released later this year. There are 62 open > tasks in Phabricator tagged with "MW-1.26-release". > What does being tagged with "MW-1.26-release" actually mean? T92796 and T113189, for example, were tagged by a bot after patches were merged that didn't completely close the bugs. -- 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] MediaWiki 1.26 release blockers
> On Thu, Sep 24, 2015 at 10:36 AM, Andre Klapper > wrote: > > > MediaWiki 1.26 will be released later this year. There are 62 open > > tasks in Phabricator tagged with "MW-1.26-release". > > > > What does being tagged with "MW-1.26-release" actually mean? T92796 and > T113189, for example, were tagged by a bot after patches were merged that > didn't completely close the bugs. Ostensibly: bugs that affect MW 1.26. In theory, it'd be good to get it to zero before we release in theory. Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.26 release blockers
On 2015-09-24 16:58, Brad Jorsch (Anomie) wrote: What does being tagged with "MW-1.26-release" actually mean? T92796 and T113189, for example, were tagged by a bot after patches were merged that didn't completely close the bugs. When the bot does this, I think it's just wishful thinking (and assuming that the patches do close the task). If they didn't, the project should probably be removed from the tasks. -- Bartosz Dziewoński ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.26 release blockers
On Thu, Sep 24, 2015 at 8:55 AM Bartosz Dziewoński wrote: > On 2015-09-24 16:58, Brad Jorsch (Anomie) wrote: > > What does being tagged with "MW-1.26-release" actually mean? T92796 and > > T113189, for example, were tagged by a bot after patches were merged that > > didn't completely close the bugs. > > When the bot does this, I think it's just wishful thinking (and assuming > that the patches do close the task). If they didn't, the project should > probably be removed from the tasks. > > This. I'm seeing a number of non-blockers marked as blockers. Help is welcome cleaning those out. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Gerrit Cleanup Day: Wed, Sep 23
On Tue, 2015-09-01 at 00:27 +0200, Andre Klapper wrote: > I'm happy to announce a Gerrit Cleanup Day on Wed, September 23. Thank you to everybody who participated yesterday and took the time to review patches, reduce our backlog, and give feedback to contributors! We collect feedback & "lessons learned" about our Code Review Cleanup Day experiment in https://phabricator.wikimedia.org/T113378 Please raise your voice! It will help our goal to reduce code review queues and waiting times [1] and coming up with a plan how to prioritize code review of patches contributed by volunteers [2]. Thanks, andre [1] https://phabricator.wikimedia.org/T101686 [2] https://phabricator.wikimedia.org/T78768 -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Do you run mediawiki on shared hosting? Tell us about it
Brian Wolff writes: >I feel like the types of people who use shared hosting are very unlikely to be >following this list. I am one of those people. I happily use shared hosting for MediaWiki because (1) it is very cheap and (2) I don't have to maintain the OS. DanB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.26 release blockers
On Thu, Sep 24, 2015 at 8:25 AM, Greg Grossmeier wrote: > > What does being tagged with "MW-1.26-release" actually mean? T92796 and > > T113189, for example, were tagged by a bot after patches were merged that > > didn't completely close the bugs. > > Ostensibly: bugs that affect MW 1.26. In theory, it'd be good to get it > to zero before we release in theory. > We have a few tens of thousands of open MediaWiki-related tasks, most of which probably "affect" MW 1.26 in some way. Using #MW-X.XX-release for tracking blockers is just not realistic; that project gets added to any task where there was any recent progress (and it's probably not present on tasks where nothing was merged recently, even if it's about a serious bug that should block the release) . There should be a separate, manually added project for blockers. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] OAuth handover
Hi all, OAuth support was added to MediaWiki two years ago, and has seen some significant uptake. (In case you are not familiar with it, OAuth[1] is a feature through which users can allow tools to act in limited ways through their account, without giving out their password. See Crosswatch[2] for an example.) Tools need to be whitelisted to get access to OAuth; this was done by an ad-hoc group of developers, without any explicit rules of what to accept. The plan was always that eventually the community would do it in a self-governing way, similar to how bot requests are handled (except that OAuth tool permissions are managed globally), but no one got around to actually arrange it. So let's change that! I set up a discussion page on Meta: https://meta.wikimedia.org/wiki/Requests_for_comment/OAuth_handover Your help is needed to turn this into a functioning policy. Please follow up there to keep the discussion centralized. [1] https://www.mediawiki.org/wiki/Help:OAuth [2] https://tools.wmflabs.org/crosswatch/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki 1.26 release blockers
> Using #MW-X.XX-release for > tracking blockers is just not realistic; that project gets added to any > task where there was any recent progress (and it's probably not present on > tasks where nothing was merged recently, even if it's about a serious bug > that should block the release) . There should be a separate, manually added > project for blockers. See: https://phabricator.wikimedia.org/T113628 "Change how ReleaseTaggerBot handles major MW releases" My opinion is that the #MW-X.YY-release projects should only be for: * Before X.YY is released: Issues deemed blockers of the release * After X.YY is released: Issues that are present in X.YY and are important enough to include in a point release (if it gets fixed). What ReleaseTaggerBot is doing by tagging all tasks that had an associated patch merged is not helpful without yet more manual intervention. Robla's proposal[0] isn't a bad idea. I'd suggest a better name than "check-this"[1] but the concept is sound. The only tasks still open in #MW-1.27-check-this would be ones that had an associated patch merged but were either resolved then reopened or never resolved at all. These tasks shouldn't be listed as "fixed" in the 1.27 release notes and should be acted upon in some other reasonable way[2]. This simple fix (ie: not having ReleaseTaggerBot use #MW-X.YY-release for it's work) would simply the whole process and leave us with projects that mean one thing at any time. Greg [0] from IRC: < robla> For 1.27, it might make sense to have nee Forrestbot use a new tag (e.g. "1.27-check-this") and then have a single blocking "MW-1.26-release" task which is "clear out the '1.27-check-this' queue" < robla> erMW-1.27-release, that is [1] After typing most of this email, a good suggestion would be "#MW-1.27-release-notes". At release time, all tasks marked as "Resolved" should be automatically listed as "Tasks closed in 1.27" in the Release Notes. All tasks still open are reviewed by a human. See also [3]. [2] 1) Is it a blocker of the release (as deemed by the release team, mostly Chad H, with me helping where I can)? Then go get someone to fix it now, change mind and make it not a blocker, etc etc 2) Was some meaningful progress made worthy of a mention in the release notes? If yes, do something, if not, then it's great that the default was not to include this task. 3) Remove from #MW-X.YY-release-notes is it shouldn't be included in the "Tasks closed in 1.27" part of the Release Notes. 4) etc... Humans are great at this part. -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Help needed with reading strategy process
Thanks for those thoughts, C. Scott. I, for the most part agree, but want to add some context and some thinking around this issue exactly as it has come up a bit. Though involved in the process, the thoughts below are my own interpretation. For expediency's sake, this process started with the reading team, with a focus on what 'we' as a team should do (the trees). But as we embarked on the strategic process, we quickly uncovered that our primary strategic problems (the forest) were probably not ones we could solve by ourselves. I think artificially limiting ourselves to this footprint would have shut down creative thinking quite a bit and I, at least, felt it was necessary that we understand and have ideas around the larger issues impacting our readers. As a team, collectively identifying the forces that impact our work, whether in our control or not, was incredibly powerful and enlightening. So, I think you're right that most meaningful strategies we would consider would involve collaboration with (or even ownership by) other teams. For this reason, and others, a very important part of this process is communicating out our findings and our assumptions and then collaborating with other team's as necessary. For example, *if*, as part of our process, we suspected that the strategy that would impact our readers the most would be to include more videos on the site, *one* of the 'tests' of this strategy would be: is this something we can solve or is this something we could have a meaningful impact on. We would welcome external input on how to answer this. If the answer is 'no', we would tell everyone "hey, this is not going to be 'Reading's' strategy, but we think it is a killer strategy for readers that we would like to support editing/community/etc. on..." Let me know how that sits. I'm going to be offline until Monday, so expect a delayed response on my part. -J On Wed, Sep 23, 2015 at 9:35 AM, C. Scott Ananian wrote: > Let's consider one of my pet bugbears: Chinese wikipedia. Our > readership numbers are way below what we'd like, and as I understand > it, total # of editors and articles is low as well. So obviously a > problem for the reading team, right? > > However, a solution needs to grapple with the problem of creating > content for zhwiki, which would involve language engineering and the > editing team. Handling language variants better for reading would be > good, too, but (AFAIK) we don't have a single active member of zhwiki > on staff (according to > https://office.wikimedia.org/wiki/Community_engagement/Staff_involvement), > and just a single engineer fluent in Mandarin (according to > https://office.wikimedia.org/wiki/HR_Corner/Languages). [My numbers > could be slightly off here, forgive me if so. But clearly we don't > have a *huge presence* from zhwiki on-staff, the way we do for, say, > enwiki.] So maybe we need to involve HR? > > There are politics involved, too: perhaps the solution would involve > the Community Engagement team, to try to build up the local wikipedia > community and navigate the politics? > > My point is that even a narrow focus on increasing page views fails to > address the more fundamental issues responsible, which spill outside > of the team silo. So a strategy session isolated to the reading team > risks either missing the forest for the trees (concentrating only on > problems solvable locally), or else generating a lot of problems and > discussion on issues which can't be addressed without involving the > wider organization. (I rather expected to see the former, but most of > the issues currently on > https://www.mediawiki.org/wiki/Reading/Strategy/Strategy_Process seem > to be the latter.) > > I think a strategy process probably needs a mix of both near- and > far-sightedness. Identifying issues which can be solved by the team > itself (better engagement with users, for example), but also having a > process for escalating issues that require a more organizational > response. The latter seems especially important for a team composed > mostly of remote workers, since there aren't the same informal > watercooler-talk mechanisms available for building awareness of > broader needs. > --scott > > -- > (http://cscott.net) > > ___ > 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] Gerrit Cleanup Day: Wed, Sep 23
Is there any statistics or graphs that shows how many patches are merged/abandoned/received love by others? -- revi https://revi.me -- Sent from Android, sorry for top-posting -- 2015. 9. 25. 오전 2:18에 "Andre Klapper" 님이 작성: > On Tue, 2015-09-01 at 00:27 +0200, Andre Klapper wrote: > > I'm happy to announce a Gerrit Cleanup Day on Wed, September 23. > > Thank you to everybody who participated yesterday and took the time to > review patches, reduce our backlog, and give feedback to contributors! > > We collect feedback & "lessons learned" about our Code Review Cleanup > Day experiment in > https://phabricator.wikimedia.org/T113378 > > Please raise your voice! > > It will help our goal to reduce code review queues and waiting times > [1] and coming up with a plan how to prioritize code review of patches > contributed by volunteers [2]. > > Thanks, > andre > > [1] https://phabricator.wikimedia.org/T101686 > [2] https://phabricator.wikimedia.org/T78768 > > -- > Andre Klapper | Wikimedia Bugwrangler > http://blogs.gnome.org/aklapper/ > > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
