[14:00:49] #startmeeting CI weekly triage [14:00:49] Meeting started Tue Sep 1 14:00:49 2015 UTC and is due to finish in 60 minutes. The chair is hashar. Information about MeetBot at http://wiki.debian.org/MeetBot. [14:00:49] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [14:00:49] The meeting name has been set to 'ci_weekly_triage' [14:01:01] #link https://www.mediawiki.org/wiki/Continuous_integration/Meetings/2015-09-01 Agenda [14:01:19] o/ [14:01:34] \o [14:01:37] #link https://plus.google.com/hangouts/_/wikimedia.org/ci-weekly Google hangout [14:01:57] #topic Action restrospective [14:02:00] #link https://www.mediawiki.org/wiki/Continuous_integration/Meetings/2015-08-25/Minutes [14:02:23] Had not much to do from last meeting apparently [14:02:30] #topic Wikidata browser test jobs [14:03:32] #link https://phabricator.wikimedia.org/T110510 [14:04:11] #link https://integration.wikimedia.org/ci/job/browsertests-Wikidata-WikidataTests-linux-firefox-sauce/ Failling job [14:04:43] Given I am on an item page [14:04:51] no implicit conversion of String into Integer (TypeError) [14:04:51] 00:00:20.648 /mnt/jenkins-workspace/workspace/browsertests-Wikidata-WikidataTests-linux-firefox-sauce/tests/browser/features/support/pages/item_page.rb:34:in `[]' [14:04:51] :( [14:05:28] https://integration.wikimedia.org/ci/job/browsertests-Wikidata-WikidataTests-linux-firefox-sauce/jobConfigHistory/ [14:07:20] #link https://integration.wikimedia.org/ci/view/BrowserTests/view/Wikidata/job/browsertests-Wikidata-WikidataTests-linux-chrome-sauce/ Actually falling job is the chrome one [14:07:41] #link https://integration.wikimedia.org/ci/view/BrowserTests/view/Wikidata/job/browsertests-Wikidata-WikidataTests-linux-chrome-sauce/jobConfigHistory/ [14:10:07] #link https://integration.wikimedia.org/ci/job/browsertests-Wikidata-WikidataTests-linux-chrome-sauce/jobConfigHistory/ [14:21:41] # CI isolation project [14:21:52] #info Now named CI scaling project [14:22:03] #action Rename project in Phabricator [14:23:13] #agreed to rename the CI isolation project to CI scaling [14:23:49] #info https://phabricator.wikimedia.org/T110693 MySQL database for Nodepool [14:24:30] #info https://phabricator.wikimedia.org/T107268 Bump Nodepool to support statsd 0.3.0 [14:26:23] #info Creating images using disk-image-builder !!!!!!!!! [14:28:12] #info .plan : hashar to conclude nodepool install then migrate integration/config.git jobs and later pywikibot/core jobs [14:30:20] #info Hashar and Dan discussed about using LXC to run jobs. Potential challenge is creating the reference image and then compile a Jenkins job as a sequence of commands to run in a LXC container. Might do a POC in September [14:31:18] #topic Wikidata and composer [14:31:38] #info composer-merge-plugin no more blocking. Jan lacks time to convert the existing jobs though [14:32:43] #topic Jobs compatibility with old release branches [14:33:44] #info Conversion to generic composer/npm jobs cause jobs to fails on release branches that are not ready for it yet [14:37:31] #agreed hashar to emit a proposal to wikitech-l to bring npm/composer support to REL branches. [14:38:36] #topic Unique entry point (make test? ) [14:39:08] #info Pro: offers liberty to dev, Con: does not let us ensure the proper jobs are running (such as npm/composer based) [14:41:17] #info Jan points npm/composer can be badly configured. legoktm dashboard shows the tools being used https://www.mediawiki.org/wiki/User:Legoktm/ci [14:41:22] #link https://www.mediawiki.org/wiki/User:Legoktm/ci legoktm dashboard [14:41:31] #link https://github.com/legoktm/tools-ci legoktm dashboard source code [14:42:57] #info alternative to a make file would be using a config file that says something like npm=yes, composer=no. i.e. you could enable individual entry points. [14:43:55] ahh [14:44:26] such as .wmfci.yaml -:} [14:48:40] #info Paladox proposed a lot of changes to mediawiki repositories and CI config. Have to test each of them individually before approval though :-/ [14:51:05] #agreed jzerebecki to fill a task requesting to make it easier to run composer/npm on repo that are not configured yet (using Zuul experimental pipeline) [14:52:15] #info Already solved by legoktm ! npm / composer-tests are in experimental [14:53:16] #topic Next meeting [14:53:33] #agreed Next meeting on Tuesday September 8th at 16:00 CET (14:00 UTC) [14:56:29] #endmeeting [14:56:30] Meeting ended Tue Sep 1 14:56:29 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [14:56:31] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-09-01-14.00.html [14:56:31] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-09-01-14.00.txt [14:56:31] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-09-01-14.00.wiki [14:56:31] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-09-01-14.00.log.html [18:01:02] spagewmf ? [18:01:22] Hi, just figuring out how to announce with MeetBot [18:01:33] ah :) [18:01:38] #startmeeting [18:01:38] spagewmf: Error: A meeting name is required, e.g., '#startmeeting Marketing Committee' [18:02:36] #startmeeting discuss the mw.org API namespace [18:02:36] hi ricordisamoa [18:02:36] hi spagewmf [18:02:36] #startmeeting discuss the mw.org API namespace [18:02:36] Meeting started Tue Sep 1 18:02:05 2015 UTC and is due to finish in 60 minutes. The chair is spagewmf. Information about MeetBot at http://wiki.debian.org/MeetBot. [18:02:36] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [18:02:36] The meeting name has been set to 'discuss_the_mw_org_api_namespace' [18:02:37] spagewmf: Error: Can't start another meeting, one is in progress. Use #endmeeting first. [18:03:12] topic :) [18:03:16] * Niharika_ waves [18:04:02] #topic make Web APIs hub a good "front door" to Wikimedia APIs [18:04:03] hello [18:04:03] Before that.,.. [18:04:08] what about asking who is here for the meeting about the Web APIs Hhub? [18:04:19] o/ [18:04:26] Me! [18:04:29] \o [18:04:48] sure, also qgil maybe you could mention it's starting in #wikimedia-tech, #mediawiki ? Or I will [18:04:51] o/ [18:05:25] :-) [18:05:25] I can do that [18:05:38] #link https://phabricator.wikimedia.org/T110108 [18:05:52] a little history: at the Zurich hackathon, people met about coming up with a developer hub to encourage third-party developers to use our APIs and data [18:05:55] hello [18:06:30] when I switched to Tech Writer, I worked on it, and it morphed into [18:06:36] #info https://www.mediawiki.org/wiki/Web_APIs_hub project page [18:08:46] the page and related content is at https://www.mediawiki.org/wiki/API:Web_APIs_hub [18:08:46] (announced in #mediawiki, #wikimedia-dev, and #wikimedia-tech [18:08:47] ) [18:08:47] #agreed qgil is awesom-o [18:08:47] :) [18:08:47] our goal in this meeting is to get feedback and concrete actionable steps so that Web APIs hub becomes *a* front door into the APIs [18:09:19] the current https://www.mediawiki.org/wiki/API:Main_page becomes API:Introduction_to_the_action_API , still a vital page [18:09:54] as you probably know, with RESTBase and Wikidata Query Service we have more than just the action API these days. [18:10:27] please everyone, comment and interject "That's a dumb idea" "Over my dead body" :-) [18:10:42] Over my dead body [18:10:49] I think we can find something shorter than "Introduction to the action API" [18:11:45] legoktm: conversation at https://www.mediawiki.org/wiki/API_talk:Main_page#Renaming_this_page.2C_front_doors_to_the_APIs [18:12:02] "API:Action" seems like a logical title to me [18:12:05] Is the objection about the new name of the page or about that fact that it is not the main page anymore? [18:12:17] the downside is that it becomes significantly less discoverable [18:12:23] qgil: the former [18:12:37] ricordisamoa ? [18:12:57] my thinking is there's nothing special about "API:Main_page". We should name pages for what they contain [18:13:00] reserve the API ns for the action API and create new pages under https://www.mediawiki.org/wiki/RESTBase? [18:13:17] I don't think "Action" alone is descriptive enough, but this might be bikeshedding [18:13:48] ricordisamoa: what about Wikidata Query Service? what about (I am confused here...) citoid, graphoid, parsoid, xxoid ? [18:13:50] We do need a main page, regardless of its title, though. [18:13:57] yes. [18:13:59] ricordisamoa: RESTBase is an implementation, but the docs should be about APIs [18:14:27] of course https://www.mediawiki.org/wiki/API would be a new hub for all APIs [18:14:49] fhocutt: there was a wikitech-l discussion that wound up at "PHP action API", and then gwicke announced the shortening to "Action API" in https://en.wikipedia.org/api/ [18:15:05] I think that's reasonable, just keep the "API" in there [18:16:13] everyone, take a look at the {{API}} navigation in https://www.mediawiki.org/wiki/API:Main_page , it's starting to show the idea of multiple APIs but "action API" is the big kahuna [18:16:20] "https://www.mediawiki.org/wiki/API" is a redirect. We can keep it as main URL or we could go for something mre fancy, but this is something that we can discuss in a specific task. [18:16:39] It seems that we agree that a new main page is needed, and the current one will cover the Action API only [18:17:39] qgil: The big issue is whether https://www.mediawiki.org/wiki/API:Web_APIs_hub can be the API redirect and the "MediaWiki APIs" page. [18:17:54] sorry, I mean everyone, not just qgil [18:18:21] many users are probably interested in 'how can I best do X', and don't care as much about 'using API Y' [18:18:52] This has been spagewmf and my aim so far. I would welcome a list of blockers (if any) for having that page as main page for the API namespace. [18:18:57] so, some amount of introduction / overview focused on use cases could be useful [18:19:24] spagewmf: That discussion only "ended up" at "PHP action API" because you resurrected it a year later with that suggestion, I believe. [18:19:58] gwicke: right, that's why https://www.mediawiki.org/wiki/API:Web_APIs_hub is more about the what (free open knowledge on WMF wikis), then showcasing some how do others, then links to sandboxes, then more conventional links at #Build [18:20:12] *How do others do things [18:20:52] we need an API bucket at https://www.mediawiki.org/wiki/Special:Search [18:22:30] so if someone searches for "recent changes" and selects API they find API:Recentchanges and RCStream [18:22:31] anomie: well yes, circumstances advanced with the /api/ addition and the decision to put this content in the API namespace. Each decision wasn't easy and I'm willing to re-evaluate if it was the right one [18:22:31] ricordisamoa, interesting, +1 [18:22:54] As for [[mw:API:Web APIs hub]]... There's two screenfulls of large pictures and bold text that have to be waded through to find in comparatively small text at the bottom the links to actual API documentation. [18:23:35] ricordisamoa: the default search includes Manual, Extension, API, Skin. If it's not confusing to add API specifically as well, we can do it. [18:23:51] #action Phab ticket to add API namespace to mw:Special:Search [18:23:57] anomie, this is the type of blockers that we welcome. Let's define them, discuss them, and solve whatever needs to be solved. [18:24:48] anomie: yup, again "encourage third party developers to use Wikimedia APIs and data". We hope it's better for that audience and not absolutely terrible for MediaWiki developers [18:25:20] * robla waves sheepishly, having realized he should have been paying attention longer [18:25:59] (Hi ;) ) [18:26:07] Hello RobLa!!! [18:26:22] We can agree that https://www.mediawiki.org/wiki/API:Web_APIs_hub is meant to become the new main page, but it will require some improvements first. [18:26:25] anomie: I think developers visit API / API:Main_page once or twice, then look for signposts to what they really want [18:26:34] Bugs / requests are welcomed as blockers of... [18:26:55] BTW what license are API data released under? Nothing at https://meta.wikimedia.org/wiki/Research:Data#Access_2 or https://meta.wikimedia.org/wiki/Research:Data/FAQ [18:27:19] corporate users will want to know [18:27:22] I would love to have the detailed invasive privacy-sucking clickstream of new visitors to mediawiki.org, but it's not the way WMF rolls :-) [18:27:32] blockers of... https://phabricator.wikimedia.org/T105133 ? [18:27:36] spagewmf: I agree with anomie that starting with a compact overview / list of apis could help people find docs quickly [18:27:38] spagewmf: I can't speak for any other developers, but the few times I use the on-wiki docs I start from [[mw:API]] and look for the links. But I usually just use the auto-generated documentaton. [18:27:54] the case studies are useful too, but appeal to people with more time on their hands [18:27:58] spagewmf: I think there could be easier-to-find signposts to the various documentation instances [18:28:12] the case studies would have been super useful to me getting started [18:28:45] fhocutt: thanks! BTW there will be another soon on Wikidata [18:29:00] anomie: when I use the on-wiki docs, I usually either use the search bar or link-hop [18:29:31] the autodoc at api.php is easy to dig only if you're used to MW [18:29:38] ricordisamoa, the license of "API data" is the same as the license of the equivalent content? [18:29:46] thanks for the feedback, it's very useful. Again, the links are there, but starting down at https://www.mediawiki.org/wiki/API:Web_APIs_hub#Build [18:30:35] ricordisamoa: when I was learning it, I mostly used autodoc + api sandbox [18:30:42] ricordisamoa: Off the top of my head, the parts of the (action) API response that have actual content is the license of that content. Auto-generated documentation is probably under the terms of MediaWiki and/or the extensions providing the messages. Most of the rest is probably not rising to the level of copyright protection. But ask a lawyer if you really want to know. [18:31:25] anomie: I don't care, but someone else might [18:31:56] eg, is attribution mandatory when aggregating usercontribs data? [18:32:17] Mmm can we stick to the agenda? [18:32:33] oksorry [18:32:51] there's a phab task for incorporating license information [18:33:56] Alright, so https://www.mediawiki.org/wiki/API:Web_APIs_hub needs to make happy not only new users, also the regular visitors looking for something more specific. [18:33:57] OK so people use navigation from the main page, Web APIs hub has it but it's lower down. Maybe it could have an expandable navigation at the bottom. I really don't want the {{API}} at the top of the page [18:35:36] It looks like weed as #action Create a task to discuss improvements required for https://www.mediawiki.org/wiki/API:Web_APIs_hub [18:36:25] spagewmf ? [18:37:15] https://phabricator.wikimedia.org/T93062 is "Define the navigation elements"; yes we should have a phab task specifically for making Web APIs hub a front door, then people can feed back there [18:37:26] ok [18:38:06] #action spagewmf to create a task to discuss improvements required for https://www.mediawiki.org/wiki/API:Web_APIs_hub [18:38:12] next? [18:38:29] please don't be polite. The page has good intentions, but the implementation is (Cartman voice) weeeak [18:38:55] :) [18:39:27] spagewmf, next topic? 20 minutes to go... [18:40:19] I have a meta question about changing mediawiki.org. I'm trying to put things in phab tasks, mention on API_talk:Main_Page, mention on https://www.mediawiki.org/wiki/Project:Current_issues, but I don't get a lot of feedback. But I don't want this to be seen as WMF steamrolling a bunch of disruptive changes to mediawiki.org [18:41:11] are there other forums where people who care about mw.org gather? [18:41:11] #topic how to get more feedback and know when there is consensus [18:41:26] spagewmf: occasional updates to wikitech-l or mediawiki-api? [18:41:29] (It was your idea to use MeetBot ;) ) [18:42:22] I think we could make more use of mediawiki-api, although I'm not usre how on-topic would be discussions and questions specific to working woith Wikimedia data.. [18:42:43] I care about mediawiki.org and lurk IRC [18:43:01] c'mon Krenair you're everywhere :) [18:43:02] fhocutt: I was going to say, I'll spam mediawiki-api list more. There are many people who contribute a lot to mw.org docs, but many of them aren't here (or there). #action make virtual team T-shirt ? :-) [18:43:19] OK, well if nobody has more suggestions about that, next up is... [18:43:43] no wait [18:44:01] I think it has been clear that significant changes in mediawiki.org need to be proposed there. [18:44:19] Another thing is that we can keep our tasks in Phabricator, because it is more efficient (most of the times) [18:45:14] But we should not be expected to suggest everything everywhere several times, that is not efficient [18:45:34] spagewmf, okay, so I've just looked at https://www.mediawiki.org/wiki/API:Web_APIs_hub and I'm confused [18:45:44] Why is this on mediawiki.org and not wikitech.wikimedia.org? [18:46:18] qgil: there being wikitech-l and mediawiki-api list? I agree. One thing with Phabricator is the task expresses the problem and the actual proposed change is in a comment. [18:46:34] Because it is everybody's interested to promote a single site as opposed to diverisfy efforts between a site that struggles and another than nobody knows or uses. [18:46:50] This has been discussed long ago [18:46:53] +1 [18:47:02] wikitech.wikimedia.org seems more about internal docs for labs sysadmins [18:47:14] wikitech.wikimedia.org is for wikimedia-specific technology [18:47:21] mediawiki.org is for the generic wiki software [18:47:33] It is very very clear upon opening https://www.mediawiki.org/wiki/API:Web_APIs_hub that it is only about wikimedia sites [18:47:48] Krenair: yes, it is a shift. But third-party developers want to access free open knowledge, and that means Wikimedia sites. I'm trying to be clear that MediaWiki powers the sites. [18:47:53] Krenair, are you thinking about definition or about users? [18:48:09] It cannot become the MediaWiki.org API Main Page in this state. [18:48:34] I keep saying that this old mantra benefits nobody [18:48:37] again, API:Main_Page isn't going away. That will continue to cover the (MediaWiki web) action API [18:49:01] MediaWiki extensions are very barely in scope for that namespace. [18:49:09] Who is using the MediaWiki APIs for Wikimedia content and who are using the MediaWiki API for something else? [18:49:17] Arguably extension APIs should go under the Extension page instead. [18:49:23] This goes well past that line. [18:49:39] Krenair: I'm not sure what you mean "MediaWiki extensions are very barely in scope for that namespace." [18:49:42] yes https://www.mediawiki.org/wiki/API:Web_APIs_hub is toooooo wikimedia-specific [18:49:50] There is a separate Extension namespace for extension things [18:50:00] Krenair, and we should go back 18 months now, just because you checked this page today? [18:50:02] Everyone that wants to automate anything on their MediaWiki site needs to use *the MediaWiki API* [18:50:10] qgil: I'm sure at least some people who have their own MediaWiki wikis or otherwise contribute to non-WMF wikis use the API for it. [18:50:22] I'm not suggesting anyone goes back to anything. [18:50:32] Krenair: at one point the new pages were in a new dev: namespace, but that was untenable and we had a long discussion about it. [18:50:39] The Web APIs hub is not limited to Wikimedia content. [18:50:56] Wikimedia content happens to be a popular and convenient subject to explain what the MediaWiki APIs can do [18:51:18] This page is all about Wikimedia content [18:51:36] and it's all about MediaWiki APIs [18:51:38] Wikimedia-specific services [18:51:50] then the examples should be added to. [18:51:53] it seems that, with the right disclaimers/footers/etc, we can make something useful for everyone, while still acknowledging the 800 lb gorilla [18:51:54] is this harming MediaWiki in any way? [18:51:57] All of which are not in core and therefore available to very very few MediaWiki sites [18:51:59] Krenair: again the "MediaWiki API" is still at mw.org:API:Main_page (really "Introduction to action API") [18:52:30] "free knowledge" is Wikimedia, not MediaWiki [18:52:43] we don't need to be overly fussy about "crossing the line" of talking about Wikimedia APIs when talking about MediaWiki APIs [18:53:03] we have 8 minutes left (though I'm happy to run over) and I want to give an update on the Blueprint skin [18:53:13] that one [18:53:19] so... 18 months ago, when the people promoting this project wanted to create a separate site to avoid discussion about Vector look&feel and traditions of the MediaWiki community.... [18:53:20] I don't mind you using Wikimedia sites to demonstrate the normal MediaWiki API available for all modern MW-based sites [18:53:32] ... we asked them and convince them not to create a site apart and contribute to mediawiki.org [18:54:28] We have talked about this project for a long time now, and it will stay in mediawiki.org -- if there is something unacceptable, let's discuss it. Again, blockers are welcome. [18:54:41] I don't care what you convinced people to do 18 months ago, you will follow and respect our project scope. [18:54:58] MediaWiki is for documentation of the MediaWiki software and related bits and pieces [18:55:04] Krenair: why the "you will follow" commanding line? [18:55:06] Not specific sites running MediaWiki [18:55:33] Krenair: "Wikimedia APIs" is a gray area. It's all open source, people are trying to figure out how to package RESTBase and other APIs so that other MediaWiki installations could use them [18:56:11] Wikitech wiki can be for whatever Wikimedia-specific technical stuff you like [18:56:40] I don't think that division describes the way we use mw.org today [18:56:45] Krenair, I think mediawiki.org needs to serve the interests of the MediaWiki community, and anything is up for discussion. [18:57:21] that was not a division I had understood to be the case. [18:57:22] gwicke, that's because Wikimedia gets away with an awful lot of out of scope stuff that should have been moved [18:57:26] examples: https://www.mediawiki.org/wiki/Parsoid, https://www.mediawiki.org/wiki/Citoid, https://www.mediawiki.org/wiki/RESTBase, https://www.mediawiki.org/wiki/Offline_content_generator [18:57:46] these are all part of the wider MediaWiki service ecosystem [18:58:02] the same way extensions are [18:58:13] Krenair: I believe a tiny fraction of third-party developers cares about any of these APIs in isolation from using them on Wikimedia sites, but I am happy to showcase interesting uses of them on non-WMF sites [18:58:27] Parsoid and OCG are very clearly relevant to MediaWiki [18:58:38] This is a wider discussion... let me just say that "putting all Wikimedia specific stuff out of mediawiki.org" wouldn't benefit the MediaWiki community, and in fact would bring the opposite effect you are probably seeking kren [18:58:43] I'm not sure about Citoid or RESTBase, they seem more generic [18:59:30] one minute left. Does anyone have to go? Is another office hour following this [18:59:45] Krenair, I think you also need to respect the fact that we have been working openly on this project for more than a year now, announcing, propising, discussing, etc openly in several places. [18:59:56] If you have objections, fine. [19:00:03] Present them and defend them. [19:00:08] I already did. [19:00:36] In the middle of a meeting that wanted to solve some details, that basically blew up.... [19:02:20] So, Blueprint. Currently I mirror the identical content to http://devhub.wmflabs.org , where it's using a different skin. [19:02:25] We will keep our plans. If the MediaWiki community really wants this hub to move somewhere else, we will find the way. [19:02:42] I just don't think that this objection here is enough. [19:02:50] (BTW the namespace discussion was https://phabricator.wikimedia.org/T369 and probably elsewhere) [19:03:27] spage: looks nice and clean, only thing is I'm not a fan of the hamburger menu at the top right [19:03:31] that skin combines sidebar navigation with the current page's TOC. [19:05:12] fhocutt, Volker_E is here. our plan is to enable Blueprint as a skin on mediawiki.org, then consider how to use it for API pages. [19:05:14] I took over big parts of development of Blueprint from prtksxna and in dialog with spagewmf [19:05:24] ah, cool [19:05:39] as an /optional/ skin on mediawiki.org [19:05:47] enable as "just another skin in PReferences". ^ right [19:06:22] again, why a different skin? [19:07:11] ricordisamoa: because looking like a 2000-era site is a disincentive to "encourage third-party devleopers to use Wikimedia APIs and data" [19:07:42] I'm not particularly bothered by a new skin, I just don't see the point. Especially with the idea of special-casing the API namespace for it [19:08:52] besides various improvements towards readability (based on research of readability) and soon-to-be offering responsive design implemenation (covering mobile readability as well), it also uses widely the widgets defined in Living Style Guide [19:08:54] Krenair: I believe there's a way to only show it to new developers and those who haven't expressed a preference, but we're kind of getting ahead of ourselves. [19:10:23] sounds like we're wearing a mechanic's coveralls full of tools and trying to fit a tuxedo on it [19:10:40] again, work towards enabling it on mediawiki.org as an optional skin, continue to have it running at http://devhub.wmflabs.org/wiki/API:Web_APIs_hub , and we'll improve it and solicit feedback. [19:10:59] ricordisamoa :) [19:11:53] OK, well thanks everyone, I _really_ appreciate your comments. We'll have some clearer phab tasks for feedback. [19:12:29] same for me, looking forward to your inputs! [19:14:13] thanks for pushing this, spagewmf, Volker_E [19:14:46] Okay, so you think it's a 2000-era site skin [19:14:54] That seems like a big issue [19:15:03] #endmeeting [19:15:03] Meeting ended Tue Sep 1 19:15:03 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [19:15:03] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-09-01-18.02.html [19:15:03] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-09-01-18.02.txt [19:15:03] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-09-01-18.02.wiki [19:15:04] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-09-01-18.02.log.html [19:16:12] O meetbot, if you make us give the meeting a name, why use such unfriendly URLs? [19:16:23] But you only really seem to be planning to solve it for the project you're currently working on, when in reality it affects a lot more. I know you can't just completely redesign the default skin like that, but still... It's not exactly ideal [19:16:37] I'll put my thoughts on the tasks [19:17:01] A: because meetbot logs are not meant to be permanent, we're supposed to copy them elsewhere. [19:17:53] Krenair: "solve it" meaning Blueprint skin just for Web APIs hub? FYI it's also on http://living-style-guide.wmflabs.org/ [19:20:13] Krenair: AIUI Blueprint currently has limited applicability. The sidebar that melds some pages with the current page's TOC lets you walk through an area, but isn't ideal for an entire site or a large set of pages. [19:20:43] I should probably become much more familiar with the skin itself before wading into such discussions :) [19:21:56] I don't have a particularly opinion on the age of skins. Maybe you're right that Vector looks too outdated, maybe not. I'm not looking to march into that debate [19:23:02] But on the assumption that it does look too old, I just think that it should be considered as a much broader issue than something we should be dealing with when considering very specific pages [19:23:13] Krenair, it's definitely not really about 'age' from my perspective (if there's a running system you should have really good arguments to change/alter it). [19:23:34] Krenair: Blueprint is certainly different. violetto_ (May Galloway) and Volker_E can express the design ethos (I think that's the right term :) ) better than me. [19:24:05] It's about research/best-practices that haven't been able to be reflected in Vector completely due several factors [19:24:35] and this research on reading has been done at places with lots of users [19:24:54] we would like to reflect that in our work for Living Style Guide [19:25:00] out of our experience [19:25:48] and if we get/have common agreement to also introduce it for the Web APIs Hub -- even better [19:26:53] but there's still way to go, no question on that [19:27:05] how much did you *use* wikis before designing the skin? [19:27:07] Krenair: special-case skin for special-case sites is easier to make happen, but there was really strong consensus to not have content live on a separate dev.wikimedia.org site. Then when we say "OK, the content will live on an existing site" and try to integrate that special-case skin, people (justifiably) bring up "schizophrenic site". [19:27:46] ricordisamoa I'm a long-term Wikipedian, started contributing in 2004 [19:27:50] hard problems, difficult choices [19:27:59] anyway, I gotta go, thanks again [19:28:20] hat off [19:28:51] so do you think it could be used for everyday editing? [19:29:16] that' definitely our target, anything else wouldn't make sense [19:29:58] but originally it was put into reality just for Living Style Guide [19:30:16] deploying to mediawiki.org as optional skin is a different story [19:30:39] ricordisamoa: FWIW I've edited pages on both those sites in Blueprint, I'd characterize myself as long-term editor not power editor [19:31:38] ricordisamoa: and we're clear about several shortcomings right now, but with your help we'll get more clarity on different corners still needed to be addressed [19:31:56] Is that the really minimalist skin that's basically just a bar up top and then the rest is just body? I really like that skin and wouldn't mind using it as my Wikimedia default. [19:32:04] Volker_E: BTW I was able to update devhub to latest Blueprint skin and reduced the number of local patches from 10 to 5. [19:32:19] spagewmf: Great! [19:32:26] harej: http://livingstyleguide.wmflabs.org and http://devhub.wmflabs.org [19:32:55] yes, that one, i like that one and i waaant iiiit [19:33:27] harej: I wired the $20 to your Paypal account, thanks for the astroturfing campaign [19:33:34] oops, that was meant to be a private message :) [19:34:06] ok, have to go for another meeting [19:34:07] thanks everybody [19:51:49] spagewmf: are you familiar with https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Tech_Ambassadors ? [19:51:56] It seems to be brand new [19:52:14] (as in, less than 12 hours old) [20:06:42] harej: yeah, see the latest discussion on the Wikitech Ambassadors list (https://lists.wikimedia.org/pipermail/wikitech-ambassadors/). [20:07:03] Aha! So that's who Samtar is.