EE

ee@lists.wikimedia.org

502 discussions

Collab team notes for Wed. 12/24
by Matthew Flaschen 24 Dec '14

24 Dec '14

Matt: Coordinated getting fhocutt flow-bot rights, and put up a patch (https://gerrit.wikimedia.org/r/#/c/181120/) to let bureaucrats grant it. It turns out the testwiki version of this is not required (since we were able to have staff members use staff rights to grant it on test wikis). However, I believe a similar patch (or expanded version of that one) will be required for production, where community members will approve the bot. Fixed the PageTriage bug that was making it unusable (though another one cropped up soon after), then deployed that and another jQuery upgrade issue (tipsy). Today I'll work on the jQuery upgrade audit (https://phabricator.wikimedia.org/T85022) and catch up on various things. Matt Flaschen

1 0

Collab Team scrum notes, Thurs Dec 18
by Danny Horn 18 Dec '14

18 Dec '14

*Matthias*: Erik fixed patch yesterday for Co-op api - ready to be merged Matthias had one question. but is okay with releasing it today. Fixed the preview bug. Worked on timestamps on hover -- make rollover state a link to topic history. Also fixed bug with timestamps not having a hover state after load more. These will go out in the new year. Co-op api bug and preview bug will both be backported, Matt will do the swat. Tomorrow: Documentation for the article feedback tool data dump, then get back to the CirrusSearch maintenance script. *Matt*: Worked on ToC -- made good progress with gap handling, still some minor problems, punting on release today. We'll get 'em next time. Reviewed and merged Co-op bug Today: Swat Co-op and preview bugs. More work on ToC -- smoother gap handling with loading topics above the one you're looking for. There are a couple blocking issues (the topic list jitters and doesn't let you scroll in some circumstances). Gap handling isn't a blocker for merging the MVP; we knew it would be a bit fuzzy and something we'll have to do more work on. It's definitely getting closer. S added a couple sentences to the gap handling card.

1 0

TOC status
by Matthew Flaschen 18 Dec '14

18 Dec '14

Since Phabricator is down for the RT migration (scheduled to be back up midnight SF time), we're using https://etherpad.wikimedia.org/p/Minimal_Viable_TOC_2014-12-17 as temporary tracking for TOC blockers. If you find any more blockers, please add them to there and then Phabricator when it's back up. Matt Flaschen

1 0

Collaboration Team scrum notes, Wed Dec 17
by Danny Horn 17 Dec '14

17 Dec '14

*Erik*: Another couple fixes for the Co-op patch which turns a page into a Flow board. Matt is planning to SWOT it out today. We can give the Co-op's flow-bot rights on testwiki; they'll have to apply to the Bot Approvals Group to use it on a real wiki. Frances filed a bug about api response: T78746 <https://phabricator.wikimedia.org/T78746>. Erik says it's fairly easy -- he'll respond on the ticket, and Matthias should be able to pick it up. Catalan fix goes out to them this morning. Worked on ToC topic list, making ordered topic lists work in the right order. Getting the info is easy, but getting it into the right order is more tricky. Working on this more today. *Matthias*: Split Phabricator search tickets up to make the plans and work clearer. Wrote documentation: https://www.mediawiki.org/wiki/Flow/Architecture/Search There's one patch ready to be reviewed. Will pick up the bug for preview showing both the preview and editing states at the same time -- T78725 <https://phabricator.wikimedia.org/T78725> *Matt*: New version of ToC <http://flow-tests.wmflabs.org/wiki/Talk:Sandbox> on flow-tests! Fixed the problem of jumping to #47 and actually getting there. (Yay!) Worked with Erik on loading the topic titles in ToC. Will SWOT the Co-op patch today.

1 0

Collab Team meeting, Tues Dec 16
by Danny Horn 16 Dec '14

16 Dec '14

*Erik*: Minor tweaks for Co-op stuff, Matt reviewed it as well. There are still some questions about getting approval for flowCreateboard. S will ask RobLa. Worked on ToC - auto-loading topic titles. Yay, that part's done. Today: getting the ToC to scroll while you scroll the other part -- that'll make it load more as you scroll down the page. *Matt*: ToC -- working on the issue about jumping to a later topic. Made a config change to set the default WMF production setting for event-logging to true. Today: Finish the ToC jumping issue. After that -- look into the issue of the *Matthias*: Worked on CirrusSearch patches, reviewed, submitted one Tomorrow -- back to the CirrusSearch configuration script S asks Matthias to update the card to help the rest of us understand what the next milestone is.

1 0

Collab Team scrum notes, Mon Dec 15
by Danny Horn 16 Dec '14

16 Dec '14

*Matthias*: Working on maintenance script for Cirrus Search -- hope to finish highlighting by tomorrow. Worked on uploading the dump for article feedback tool, uploaded it today. The big concern before Erik leaves -- we need to get Co-op set up with the ability to create Flow boards. Erik will coordinate with Matthias to make sure this can get done before the last deployment of the year, on Friday. *Erik*: Finished bug triage. Looked at Matthias' search work. Today -- will look at ToC blocker -- initially loading everything in one panel (T78569) Will coordinate with Matthias on Co-op ability. Will prepare the cherrypick for the Catalan fix, to go out with the train on Wednesday. *Matt*: Rebased ToC stack, fixed some issues. New version is on flow-tests. ToC MVP for merging: * Enough items need to load in the ToC title list to allow for a scroll bar. The list of topics should scroll so that the live title is under the header. * Clicking on #60 needs to take the user to #60. (We'll work on the gap handling after that, but we can't ship a product where you click on #60 and land on #27.)

1 0

avoiding a Talk page / Flow board dichotomy
by S Page 13 Dec '14

13 Dec '14

*{{draft}} {{random person's idea}}* !!! Executive summary: add Flow discussions to pages with {{#useFlow:1}}. Converting a Talk page to a Flow board is disruptive and controversial. It delivers better conversations (for new and average users) right now, but it will be years before Flow nails all the other use cases for talk pages (collaboration, metadata, workflows). Our workaround for that period is to put stuff other than conversations in the Flow board header (nomenclature <https://www.mediawiki.org/wiki/Flow/Nomenclature#Picture>). Flow topics live in an external cross-wiki DB separate from the page, but I haven't seen a good use case why we need the Flow board header to be in this cross-wiki DB. Maybe it doesn't have to be so black and white. Imagine a world where Flow topics appear on a talk page but it's still a wikitext talk page. Enabling Flow on a page would be like LQT – someone adds a {{#useFlow:1}} magic word to a page and it gets Flow discussions. We de-emphasize the Flow board header, because you still have an entire regular page for templates, categories, workflows and whatever. *+ No disruptive conversion* *+ No bugs with categories in Flow board header* *+ Avoid issues with changing the content model of a page* *+ No complaints about narrow Flow board header* *+ No break in the page history* *+ No need to for a tricky archive-existing script* Although admins might choose to run a bot to move old wikitext section topics to an archive when adding {{#useFlow:1}}. *+ Don't have to solve the other three talk page use cases* (collaboration, metadata, workflows) *to gain Flow's improved conversations*. *+ The Collaboration team is adding an optional feature to existing talk pages* *, rather than perception of usurpation and war* *+ We get feature parity "for free"* A number of complaints about Flow boards shift, because part of the talk page remains wikitext that users can view-source, diff, revert, monitor, etc. in the usual way. Topics are still a very different animal. Bots don't break, they will add stuff to the wikitext. Special:Search can still find text in the page (but not in its Flow topics until we do the search integration we need to do regardless of this proposal). Page move, #REDIRECT, etc. all kind-of work. *+ We gain flexibility* A pure discussion page like Talk:Beta Features/Hovercards <https://www.mediawiki.org/wiki/Talk:Beta_Features/Hovercards> can still be {{#useFlow:1}} and a minimal wikitext part. LiquidThreads did it this way and AFAIK the flexibility was useful and non-controversial. We could support different behavior, e.g. {{#useFlow:*42*}} might only display a link to Flow topics. See "Feeds" section below. There are downsides. *- Two ways to discuss on a talk page* If {{#useFlow:1}} then we would adjust the [Add topic] tab to jump to the *Start a new topic* Flow form. Still, old-timers would continue to create wikitext section topics. *- Hybrid page user experience is messy* *- Hybrid page implementation is messy and slow* MediaWiki has to load regular wikitext then load Flow topics, handle two kinds of JavaScript, etc. *- The page gets infinite scroll behavior* (People keep demanding the notion of archives, if we respond to them and provide a way to move old and closed Flow topics, e.g. to a /All_topics_archive subpage, then a talk page with Flow topics could adopt an approach where it *doesn't* scroll forever. That is orthogonal to this proposal.) *- The upcoming Flow TOC and fixed header has to coexist with regular page TOC* If Flow discussions are the last thing on the page then once you scroll down to them you're in a different kind of thing, so it's OK to get a different appearance. Like LQT. The {{#useFlow:1}} could automatically add a "Discussion topics" to the end of the regular wikitext TOC. Displaying all the Flow topic titles in the regular TOC is very hard, and impossible if there are hundreds of them, but maybe the TOC could display the first (newest) 20 topic titles. *- Need to go two places to see full history of talk page* The talk page history (probably) wouldn't show all changes to the "Topics on the page", you'll still have to go to a separate board history. *+/- "Flow board" goes away* We're already de-emphasizing actions on a Flow board. You watch individual topics, you get notified about them. "Flow board" evolves into the notion of "All the topics started on this page". *+/- People might add* {{#useFlow:1}}* to regular pages* On the rest of the web, you scroll down a page and arrive at discussions about it. There's value in splitting off discussion of an encyclopedia article from the article itself, but maybe WikiProject:Breakfast or even User:SPage doesn't need the confusion of a separate talk page. *What about Feeds?* This ties into the "Feeds <https://www.mediawiki.org/wiki/Flow/Basic_information#Feeds>" feature, for which IMO we need a more concrete plan. As I understand it, the main reason for the pain (UUIDs, storagemodels, separate revision management) of a separate cross-wiki Flow DB is so that a conversation about an image in an article can appear on the article's talk page, also on the image's talk page on Commons, on the image author's talk page on Commons, and in the subscriptions of people interested in the article or image. This is fantastic, but in order to work when one of those talk pages isn't a Flow board we have to wrestle with all the issues of a hybrid page (TOC, infinite scroll, etc.), so why not do it now? I don't know how a Feed would be enabled on a regular talk page, but it sounds like an elaboration of this, {{#useFlow:|relatedTopicFeed}}. Thanks so much for reading! -- =S Page Collaboration team engineer

5 5

Flow scrum/stand-up notes, Fri Dec 12
by S Page 12 Dec '14

12 Dec '14

Danny was out presenting *EBerrnhardson:* Fix for reverse pagination in TOC, also fixes rare non-JavaScript bug load newer topics link T76772 Patch that determines candidate choice for subpages in code review. (Hard to test this until our next bulk conversion to Flow, note community discussions around our approach anyway.) Bug triage. T78090 Catalan subpage link fix is ready for review by MattF & Matthias, for SWAT deploy Monday. EventLogging: unclear if we're logging in production. He has a basic query in flow-analytics we can +2 to graph events! Will look at Matthias search stuff. *MattF*: Going through TOC patch stack, one last one left to review. Will review ErkB's pagination fix. Will get the revised patch set on flow-tests.wmflabs.org Then will convene a meeting to figure out what's needed for a minimum viable version of the TOC so we can move this to master. Some bug triage. *Review bugs* ("Needs team triage" column) * T69714 Remove "Active x hours ago" - engineers feel no, assign to Danny to make final WONTFIX determination * T75679: Flow: Preview message looks like an error and has question mark cursor <https://phabricator.wikimedia.org/T75679> belongs in a "Needs design" column. We're 90% likely to split the Collaboration-team board and this will go in a backlog board. We talked about picking up SPage role (see separate e-mail to engineers) Don't forget 8:30 Monday team health check meeting! -- =S Page Collaboration team engineer

1 0

Re: [EE] Data purges from email archives (retitled thread)
by Pine W 12 Dec '14

12 Dec '14

There have indeed been bad experiences in the past with attempting to purge archived emails, and even if purges could be done cleanly on the public archives, the action would not remove the content from the automatic 3rd party archivers and the subscribed email accounts. It would be nice to have a solution to this kind of situation, and I hope that WMF will find one or make one. Thanks to everyone who has or is working helpfully to address today's incident and related issues. Pine

1 0

[Wikimedia Foundation] Update: Re: Justine, I’ll keep it short
by donate＠wikimedia.org 12 Dec '14

12 Dec '14

##- Please type your reply above this line -## [Wikimedia Foundation] Update: Re: Justine, I’ll keep it short You are registered as a cc on this help desk request and are thus receiving email notifications on all updates to the request. Reply to this email to add a comment to the request. ---------------------------------------------- Pine W, Dec 11 11:21 AM Hi Donor services, I'm confused. EE is a public email list. Why would a donor's name and email content be sent here? Did the donor consent to this? Also, what was the purpose of sending this email to EE? This appears to have been some kind of mistake. Thanks, Pine ---------------------------------------------- Andrey Valkov, Dec 11 05:50 AM Hi Justine, Thank you for your email. The Wikimedia Foundation does not actually manage or contribute to the editorial content of Wikipedia or our other projects. We are here primarily to provide infrastructure and support the tens of thousands of volunteers around the world who edit and contribute everyday. If you need help with an edit, you'd want to email info(a)wikimedia.org. This email address is answered by longtime project volunteers, and they can help with your question. Sincerely, Andrey Valkov Donor Services Associate Wikimedia Foundation, Inc. wikimediafoundation.org Support us! https://donate.wikimedia.org ---------------------------------------------- Justine Tenzeldam, Dec 05 12:30 PM OK. I'll consider a donation. And, if Wikipedia Editors can become more helpful and accommodating to folks like me, perhaps I'll consider more! (Trying to participate is downright painful right now.) Best Regards,Justine tenZeldam510.447.9435 (talk/txt)www.solongsuburbs.comwww.justine.webstarts.comwww.twitter.com/just… On Friday, December 5, 2014 10:34 AM, "Jimmy Wales, Wikipedia" <donate(a)wikimedia.org> wrote: #yiv5329025495 p {margin:1em 0;}#yiv5329025495 #yiv5329025495outlook a{padding:0;}#yiv5329025495 .yiv5329025495ReadMsgBody{width:100%;}#yiv5329025495 .yiv5329025495ExternalClass{width:100%;}#yiv5329025495 body{}#yiv5329025495 .yiv5329025495appleLinks a {color:rgb(0, 0, 0);text-decoration:none;} Dear Justine, Thank you for helping keep Wikipedia online and ad-free. I’m sure you’re busy, so I’ll get right to it. We need your help again this year. Please help us forget about fundraising and get back to improving Wikipedia. If all our past donors simply gave again today, we wouldn't have to worry about fundraising for the rest of the year. We are the small non-profit that runs one of the top 10 websites in the world. We only have about 200 staff but serve 500 million users, and have costs like any other top site: servers, power, programs, and people. Wikipedia is something special. It is like a library or a public park. It is like a temple for the mind, a place we can all go to think and learn. To protect our independence, we'll never run ads. We take no government funds. We survive on donations from our readers. Now is the time we ask. If Wikipedia is useful to you, please take one minute to keep it online and ad-free another year. https://donate.wikimedia.org Thanks, Jimmy Wales Wikipedia Founder | | DONATE NOW » | | You are receiving this email at justinejobsearch(a)gmail.com as a valued donor of the Wikimedia Foundation. If you do not wish to receive any future emails from the Wikimedia Foundation, unsubscribe instantly. Wikimedia Foundation, Inc. P.O. Box 98204 Washington, DC 20090-8204 United States of America enUS14 -------------------------------- This email is a service from Wikimedia Foundation. [8G43-DP57]

7 8

← Newer
1
...
9
10
11
12
13
14
15
...
51
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

EE