WMF Engineering Roadmap Update - 20130417 - Wikitech-l

List overview All Threads
Download

newer

WMF Engineering Roadmap Update - 20130417

older

browser tests now targeting beta...

[Language Engineering] Bug triage...

Greg Grossmeier

17 Apr 2013 17 Apr '13

6:06 p.m.

Hello and welcome to the latest edition of the WMF Engineering Roadmap Update. Highlights include: * Mobile resubmitted to AppStore yesterday, still waiting on the Apple Geniuses to approve ;) * QA is turning all the tests running against betalabs green (they were red from unexpected config differences); they're close. * Echo will be rolling out on en, de, and fr wiki next week on Thursday (the 25th) * Platform has moved the Ceph and Vipscaler deploys to target in May Full roadmap at: https://docs.google.com/a/wikimedia.org/spreadsheet/ccc?key=0Aoizbfxc5g6KdE… (short: http://goo.gl/7611Q ) Best, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

Show replies by date

Mathieu Stumpf

18 Apr 18 Apr

8:26 a.m.

Le 2013-04-17 20:06, Greg Grossmeier a écrit :

...

On all Mediawiki projects, or just on some of them like Wikipedia?

...

Full roadmap at: https://docs.google.com/a/wikimedia.org/spreadsheet/ccc?key=0Aoizbfxc5g6KdE…

Would it be possible to use free software solutions, which is not the case of the google spreadsheet as far as I know. Depending on the feature needed, EtherCalc may be used instead of the current solution. Other free/libre culture advocates, like the French framasoft[2] network are already using it, see [3]. [1] https://ethercalc.org/ [2] https://fr.wikipedia.org/wiki/Framasoft (Sorry, no English translation yet) [3] http://framacalc.org/_start -- Association Culture-Libre http://www.culture-libre.org/

Mark A. Hershberger

3:10 p.m.

On 04/18/2013 04:26 AM, Mathieu Stumpf wrote:

...

Wow, thank you for pointing to Framasoft. Looks like they've got some really useful stuff going on there. -- http://hexmode.com/ Imagination does not breed insanity. Exactly what does breed insanity is reason. Poets do not go mad; but chess-players do. -- G.K. Chesterson

K. Peachey

3:13 p.m.

On Fri, Apr 19, 2013 at 1:10 AM, Mark A. Hershberger <mah(a)everybody.org> wrote:

...

Wow, thank you for pointing to Framasoft. Looks like they've got some really useful stuff going on there.

Could be done very easily and neatly in a MediaWiki page...

Rob Lanphier

10:54 p.m.

On Thu, Apr 18, 2013 at 8:13 AM, K. Peachey <p858snake(a)gmail.com> wrote:

...

On Fri, Apr 19, 2013 at 1:10 AM, Mark A. Hershberger <mah(a)everybody.org> wrote:

Wow, thank you for pointing to Framasoft. Looks like they've got some really useful stuff going on there.

Could be done very easily and neatly in a MediaWiki page...

We used to do that: https://www.mediawiki.org/wiki/Roadmap After a year of maintaining, it was too much work for too little value. It's much easier for us to have a big picture view with the spreadsheet format, which unfortunately, is too difficult to maintain in a wiki page. We do a lot of real-time collaborative editing of this doc, which limits the amount of template voodoo we can get away with. As Greg mentioned, my weekend coding project is puttering around with a script to export this data to wiki[1]. The nice thing about this approach is that I can export whatever template/LST voodoo I want from this without impacting our ability to edit it in groups in real-time. That means, that instead of only having this information in a single place, we can also incorporate the information into all of the relevant activity pages. I'll happily take some guidance now as to whether I should endeavor to output a single page with lots of section markers for LST, or if instead I should output a bunch of pages (e.g. one "Foo/Roadmap" subpage per activity). that get transcluded into a single "Roadmap" page. Rather than bikeshed here about this, let's have that discussion on-wiki at https://www.mediawiki.org/wiki/Talk:Roadmap . Rob [1] Roadmap publisher script: https://gist.github.com/robla/5416776 Very much a work in progress, so I almost didn't publish. The only useful bits as of this writing are the bit to pull the info from Google Docs and push it to mediawiki.org...the conversion step is practically non-existent. I started off thinking I could deal with csv, then dabbled with html, but my preferred approach now is to parse ods from GDocs, but the code isn't really even started for that since I'm just figuring out how to do that.

K. Peachey

19 Apr 19 Apr

5:09 a.m.

On Fri, Apr 19, 2013 at 8:54 AM, Rob Lanphier <robla(a)wikimedia.org> wrote:

...

We used to do that: https://www.mediawiki.org/wiki/Roadmap ...

How about just something simple like * https://www.mediawiki.org/w/index.php?title=User:Peachey88/Sandbox/table2 or * https://www.mediawiki.org/w/index.php?title=User:Peachey88/Sandbox/table1 once they are tided up slightly, they have a similar layout as the spreadsheet and not as confusing as the previous attempt (Which I think may have been a little over worked for the end goal) although I do admit they may be harder to edit (but that maybe fixed by some template wizards)

Greg Grossmeier

3:29 p.m.

...

On Fri, Apr 19, 2013 at 8:54 AM, Rob Lanphier <robla(a)wikimedia.org> wrote:

We used to do that: https://www.mediawiki.org/wiki/Roadmap ...

How about just something simple like * https://www.mediawiki.org/w/index.php?title=User:Peachey88/Sandbox/table2 or * https://www.mediawiki.org/w/index.php?title=User:Peachey88/Sandbox/table1

Mostly it is the function of multiple people editing the document together at the same time in the same room. Until that problem can be solved on wiki, then a big wiki table probably won't be functional, at least in the current form that we've taken for this. But, I also don't know the full capabilities of what could be done, here, so if someone has a suggestion on how to work this on wiki that allows easy multi-user simultaneous editing, please do let me know. Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

Guillaume Paumier

4:02 p.m.

Hi, On Fri, Apr 19, 2013 at 5:29 PM, Greg Grossmeier <greg(a)wikimedia.org> wrote:

...

Off the top of my head, and without thinking too much about it: Solution #1: All the content lives in [[Projectname/Roadmap]] pages, in monthly sections labeled with Labeled Section Transclusion. They can be transcluded into other pages (like a big all-encompassing Roadmap page, or smaller roadmaps per team / subdepartment). A JavaScript gadget allows for easy editing of roadmap items (i.e. cells) directly from the Roadmap page (and other transclusion pages) using a modal overlay, like the StatusHelper does ( https://www.mediawiki.org/wiki/MediaWiki:Gadget-WmfProjectStatusHelper.js ) Pros: * Everything is and stays on wiki. * The roadmap for each project can be maintained by the project's team more easily, because it's closer to the project page. * The JavaScript & template hackery needed to make this work is probably not too complicated and can be inspired by the existing StatusHelper. * No edit conflicts, since people are editing different pages. Cons: * People can't simultaneously edit the same roadmap item (cell for a given month and a given project). * People need to refresh the page to see edits made by other people with the gadget. * Some template / LST / JavaScript dev work is required. Based on my understanding of how the roadmap is currently updated (each Tech director updates the roadmap for the projects that fall under their supervision), the "cons" don't seem unsurmountable. * Solution #2: All the content lives in a big table at [[Roadmap]] that can be edited simultaneously by users using a yet-to-be-developed round-tripping tool to an ethercalc instance in labs. Someone opens the page for editing in ethercalc, everyone makes their edits, and the content is saved back to the wiki page. Pros: * Everything lives on wiki. * People can simultaneously edit all parts of the document, including the same cells, and immediately see each other's changes Cons: * This requires significant dev work, probably not trivial considering the difficulties encountered when we tried to integrate regular etherpad with wikipage editing a few years back. * How do we handle edit conflicts? * This poses other questions like who is attributed for the edits, etc. An alternative to #2: the round-tripping is done manually by copy/paste or similar (as it used to be done when tech directors updated the roadmap in etherpad) if the conversion between formats isn't too lossy; This avoids having to develop an integrated round-tripping tool. Solution #3: A combination of #1 and #2: for example, the content lives in a big table at [[Roadmap]], and there's a round-tripping tool to an ethercalc instance in labs for collaborative editing, but there's also a JavaScript gadget to edit individual cells of the table. Note: LST can probably be replaced by Semantic MediaWiki if it's available on the wiki we're talking about. In a nutshell: I understand that the way the roadmap is currently updated (in a meeting of all tech directors each updating their sections) requires simultaneous editing of the /page/, but I'm not sure concurrent editing of /each cell/ is as crucial, so compromising on that may greatly simplify the problem. HTH, -- Guillaume Paumier Technical Communications Manager — Wikimedia Foundation https://donate.wikimedia.org

Greg Grossmeier

18 Apr 18 Apr

3:52 p.m.

Hello Mathieu, <quote name="Mathieu Stumpf" date="2013-04-18" time="10:26:56 +0200">

...

Le 2013-04-17 20:06, Greg Grossmeier a écrit :

* Echo will be rolling out on en, de, and fr wiki next week on Thursday (the 25th)

On all Mediawiki projects, or just on some of them like Wikipedia?

Just the English, German, and French Wikipedias. The Notifications (formerly "Echo") project team does a pretty good job of keeping this etherpad up to date with their planned deployments: http://etherpad.wikimedia.org/echo-release

...

Full roadmap at: https://docs.google.com/a/wikimedia.org/spreadsheet/ccc?key=0Aoizbfxc5g6KdE…

Would it be possible to use free software solutions, which is not the case of the google spreadsheet as far as I know.

We (myself plus the Engineering Managers) were just talking about this yesterday during the Roadmap Update Meeting (the meeting that happens right before I send out this email). Robla has a very very rough script that will (hopefully, someday) convert the GDoc into a MediaWiki table that lives on mediawiki.org. He's only working at it sporadically, unfortunately. So, yes, we completely agree. From my understanding, the home of this information was previously a mediawiki.org table, but that became too unruly when the size of it and the number of people simultaneously editing it caused usability problems. I can safely say that we aren't happy with the non-Freeness of GDocs and we wish we didn't use it in this case, but it was a stop-gap solution, and we fully intend on something else (big F Free) replacing it when we know what will meet our needs.

...

Depending on the feature needed, EtherCalc may be used instead of the current solution. Other free/libre culture advocates, like the French framasoft[2] network are already using it, see [3].

Wow! Thanks! I have to admit, I haven't put in any real time searching for a replacement, but these might be able to do it. I'll work on copying over the current version of the Roadmap to ethercalc today/tomorrow. Actually, if anyone wants to help: https://ethercalc.org/WMF_Engineering_Roadmap I *think* all of the content is copied over, but the formatting needs some work ;-). I didn't see an "import from CSV/xsl" function, but if I missed that, it might be worth a shot. No promises from our end, yet (as I don't know if we tried this already and decided against it for some reason), but this is a great option, thank you Mathieu! Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

Greg Grossmeier

19 Apr 19 Apr

8:48 p.m.

...

I'll work on copying over the current version of the Roadmap to ethercalc today/tomorrow. Actually, if anyone wants to help: https://ethercalc.org/WMF_Engineering_Roadmap I *think* all of the content is copied over, but the formatting needs some work ;-). I didn't see an "import from CSV/xsl" function, but if I missed that, it might be worth a shot.

So, update on this. I haven't worked on the formatting part at all, really, because I can't find an export functionality. I don't think I should devote more time to the formatting until I know I can "easily" import/export the content for the near term. Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

Greg Grossmeier

18 Apr 18 Apr

4:33 p.m.

As always, a correction: <quote name="Greg Grossmeier" date="2013-04-17" time="11:06:15 -0700">

...

* Echo will be rolling out on en, de, and fr wiki next week on Thursday (the 25th)

Mono

4:37 p.m.

When will commons.wikimedia get Echo? On Thu, Apr 18, 2013 at 9:33 AM, Greg Grossmeier <greg(a)wikimedia.org> wrote:

...

As always, a correction: <quote name="Greg Grossmeier" date="2013-04-17" time="11:06:15 -0700">

* Echo will be rolling out on en, de, and fr wiki next week on Thursday (the 25th)

Notifications (formally "Echo") will only be deployed to English Wikipedia, not German nor French, next week on April 25th. My apologies, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D | _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

4056

days inactive

4058

days old

wikitech-l@lists.wikimedia.org

Manage subscription

11 comments

7 participants

tags (0)

participants (7)

Greg Grossmeier
Guillaume Paumier
K. Peachey
Mark A. Hershberger
Mathieu Stumpf
Mono
Rob Lanphier