[21:00:35] Krinkle: i realized a bit late that i probably won't make it to next week's meeting. i'll give input on the phab ticket wrt integration with multi content revisions. [21:01:38] * robla waves [21:02:12] #startmeeting RFC: Improve the per-programming-language listings for our tools [21:02:12] Meeting started Wed Jul 6 21:02:12 2016 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:02:12] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:02:12] The meeting name has been set to 'rfc__improve_the_per_programming_language_listings_for_our_tools' [21:02:54] Hi all. [21:02:58] #link https://phabricator.wikimedia.org/E226 [21:03:04] #topic RFC: Improve the per-programming-language listings for our tools | Wikimedia meeting channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:03:16] hi all [21:03:35] do we have ops representatives here? [21:04:37] this is about getting a better sense of what our status quo is [21:04:50] (at least, that's what I'm hoping to get out of it) [21:04:53] * ostriches is idly watching [21:04:54] MaxSem, I beleive we're mainly (at least initially) focusing on the use-case of "how to support newcomer developers". We might (not up to me) get into the larger ops@ issue later on. [21:05:21] As I see it, the main issue is where (what page(s)) to direct newcomers to, when they are looking for new projects to work on, and they already know just 1 or 2 languages. [21:05:23] Hi All [21:05:24] how we define "wikimedia cluster"? i.e., are maps or wdqs part of it for this purpose? [21:05:37] DanielK_WMDE: OK. I made a very basic draft at https://www.mediawiki.org/wiki/Requests_for_comment/image_and_oldimage_tables#3._Replace_with_MCR - But feel free to expand on the page and/or on phab. [21:05:38] There are a number of pages that contain partial information (listed in the bottom of the description of https://phabricator.wikimedia.org/T136866 ) [21:06:03] There are 2 sites (github and openhub) that collate information automatically/semi-automatically. Plus our own scattered and incomplete listing on mediawiki.org [21:06:18] I lean towards mergism for documentation, to prevent fragmentation, hence I'm hesitant about starting the new page at https://www.mediawiki.org/wiki/Programming_languages - but I'm also not a dev, so ... [21:06:29] * Do we want to give a bunch of search links such as https://github.com/search?l=Java&q=org%3Awikimedia+&type=Repositories and/or https://www.openhub.net/p?query=wikimedia+java&sort=relevance [21:06:30] SMalyshev: I believe so [21:06:47] * Do we want to provide links to our own existing pages that contain some of this information, and focus on improving/updating them. E.g. https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker#Appendix and https://www.mediawiki.org/wiki/API:Client_code [21:06:59] ok, then we need at least Java there, we run a bunch of Java tools [21:07:01] Or something else? [EOM] [21:07:28] I would also prefer to see a big table or list [21:07:41] there's also https://www.whatcanidoforwikimedia.org/ [21:08:21] (compare with http://whatcanidoformozilla.org/ for example) [21:08:56] http://whatcanidoformozilla.org/#!/progornoprog/proglang/py is their language selector thing [21:09:14] TimStarling, ah, so something that combines everything in the existing listings, such as the links in https://www.mediawiki.org/wiki/Template:Conventions_navigation and links to the subsections of https://www.mediawiki.org/wiki/API:Client_code ? [21:09:57] As a possible newcomer developer (and having donated WUaS to Wikidata last autumn), I'd be interested in a page that even would precede https://www.mediawiki.org/wiki/Programming_languages. [21:10:26] yes on the first (Template:Conventions_navigation), not sure about the second [21:10:32] quiddity: I agree with your mergism tendencies, but started [[Programming languages]] because none of the existing editable pages really answered the question that I had [21:11:18] I mean that robla wants to create one page per programming language and put all projects related to that programming language on the specific page [21:11:22] TimStarling, nod. robla, I think that new page is a really good exxample to have available, as one possible direction to head in. I might end up utilizing it as the location for the large table suggested. [21:12:07] I think [[Programming languages]] is fine, but I'm less convinced about e.g. [[Ocaml]] (which doesn't exist yet) [21:12:10] as a newby to this convo where is the task or rfc on-wiki, I'm not clear on what the meeting subject means exactly [21:12:14] I wonder if that page should be just a category [21:12:20] chasemp, https://phabricator.wikimedia.org/T136866 [21:12:33] i.e. Category:Projects using Python [21:12:40] TimStarling: I'm actually not sure if we should create new pages, but just noted that we have [[Python]] but not [[Ruby]], and didn't really even have [[PHP]] until recently [21:12:47] I would prefer to having a page or category or something on-wiki. I think the github code base detection is pretty bad tbh. [21:12:59] Category:Projects using OCaml etc [21:13:06] I think a table with sections for each language would be a good starting point, and if it becomes unweidly, we can split into separate pages [21:13:09] It's bad with multi-language codebases. [21:13:09] chasemp, but it's tangentially related to the larger questions asked in https://phabricator.wikimedia.org/T136866#2428055 [21:13:18] It's completely off-base on repos mostly made up of submodules [21:13:23] (eg mediawiki/extensions) [21:13:46] If there was something on this page, for example - https://www.whatcanidoforwikimedia.org/ - about newcomer developers participating in this ArchCom process, in these Office Hours, and then something about how to write a RFC in Wikimedia Phabricator, that could work. Might that be possible, Tim? [21:14:11] quiddity: ok thank you I was thinking it was aimed at a list of official languages rather than a survey, makes sense [21:14:51] Is throwing new developers straight into RfC processes a good idea? [21:14:59] Sounds like it'd be information overload. [21:15:16] ostriches: no, not my hope [21:15:24] yeah, it's probably not the easiest starting point [21:15:31] ostriches, nod, that was my perspective, too. The subpages for each, contain more details, but are harder to discern. (e.g. the multicolour line at the top of https://github.com/wikimedia/apps-android-wikipedia which shows "Python 1.1%") [21:15:40] Scott_WUaS: maybe you are looking for https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker ? [21:15:45] we could definitely improve that page though, you know it links to a phab query that includes closed bugs [21:16:31] yeah maybe www.whatcanidoforwikimedia.org can link to [[How_to_become_a_MediaWiki_hacker]] [21:16:47] are we thinking of another microsite here? :/ [21:17:20] quiddity: Yeah that's not bad, but stuff like https://github.com/search?l=Python&q=org%3Awikimedia+&type=Repositories is useless. [21:17:29] (again: mw/extensions is not python lol) [21:17:40] Krenair, definitely not! I'm hoping that we conclude that I should focus on improving only mediawiki.org pages. But, I'm willing to also take a stab at improving openhub/github links/listings, I can figure out how. [21:17:42] Krenair: no, I don't think so [21:17:51] I/we* [21:18:14] quiddity: How do you propose improving what github spits out? [21:18:48] bd808: Thanks, having donated WUaS to Wikidata, I think it's contributing to WMF by developing in both Wikidata and MediaWiki that I'd be interested in learning about, possibly with Phabricator and RFCs after a few months of Office Hours, and from here - https://www.whatcanidoforwikimedia.org/ [21:18:54] ostriches, I know I can improve the openhub listings (as Nemo suggested). I'm not sure about github. [21:19:01] :) [21:19:08] robla: is this only about recruitment at the moment, or do you think this process of documenting how programming languages are used would help with a future discussion about what programming languages we should use for new projects? [21:20:00] TimStarling: good question. I'm happy to get into the deeper question if quiddity and everyone else wants to [21:20:23] so I think the first step would be taking the list at https://www.mediawiki.org/wiki/Upstream_projects#Invented_Here and others and sorting them by programming languages into a table or something? [21:20:31] I'm satisfied (thanks!) with the feedback and input on my concern. Feel free to go deeper. [21:20:31] and then we'd figure out how we want to present that data to new users? [21:21:36] or am I misunderstanding? [21:21:41] I see there's a lot not listed in Invented_Here... is there some procedure to keep it up to date? Or at least telling people it exists (I had no idea)? [21:21:55] legoktm, nod, I'll start a couple of demonstration tables (sometime over the next couple weeks) and ask for further feedback in the task (https://phabricator.wikimedia.org/T136866) [21:22:06] legoktm: this is the first time I've looked at that page in this context. interesting idea... [21:22:27] * robla can't remember if he's ever looked at that page [21:22:36] quiddity: sounds good :) [21:22:44] [[Upstream projects]] wouldn't have clued me in that there's a list of our own projects on it [21:22:45] :) [21:22:53] SMalyshev: nope, like most of our docs it's always out of date [21:22:57] (TimStarling, RobLa and bd808: And perhaps how developing in both Wikidata and MediaWiki would work programming language-wise and from here - www.whatcanidoforwikimedia.org and https://phabricator.wikimedia.org/ - could be a way in). [21:23:06] yeah, it's like on Windows you click on Start to shutdown :) [21:23:26] that Upstream page, and https://www.mediawiki.org/wiki/Developers/Maintainers, are interestingly tangential. I'd love to combine ALL THE THINGS into a giant table, but we'd need monitors 3x wider. >.> [21:24:04] legoktm: that's why I think using something like categories may be more resistant to neglect... [21:24:51] * robla agrees with SMalyshev that we need to think about neglect-resistant solutions [21:25:01] maybe! [21:26:34] quiddity: 4 dimensional tables ;) [21:27:07] let's put all those projects on Wikidata and just query it :) [21:27:18] :) [21:27:31] in a previous life I would have said SMW ;) [21:27:44] Maybe I'll also take a look at our existing navboxes, and see which could be best utilized on Upstream and Developers/Maintainers. [21:27:53] DanielK_WMDE: I'm guessing SMalyshev is only half kidding :-) [21:28:04] robla: you are guessing right :) [21:28:24] RobLa: Wikidata-centrism makes much sense :) [21:30:14] * robla goes back to T136866 to see what questions we should try to resolve [21:30:53] To add to Quiddity's observation from yesterday: "So, let's focus tomorrow's conversation on helping newcomers identify "What can I work on in language foo"" I'd explore how and in what programming langauges ... and especially in Wikidata [21:31:08] continuing with the topic of crazy ideas, Wikibase install doesn't have to be Wikidata... just saying... [21:31:37] and in Wikidata's process (Wikidata is holding an office hour tomorrow too) [21:33:32] so....if some developer (WMF included) wanted to deploy an extension involving non-PHP code, what would they need to consider? [21:33:56] well we already have JS [21:34:34] Krenair: sure...so....let's talk about server languages, say a new Node.js service [21:34:43] wouldn't be mediawiki and wouldn't be an extension [21:34:48] robla: an extension? That pretty much by definition needs to be PHP [21:35:01] yeah mediawiki extension == PHP/JS [21:35:09] but service can be pretty much anything [21:35:14] we have some extensions that shell out, or are clients for HTTP services [21:35:31] we have nodejs, python, java, probably c[++] too [21:35:32] yeah we have OpenStackManager [21:35:35] * Krenair runs [21:36:03] the deploy part is the key probably in robla's question [21:36:14] bd808: yup [21:36:17] setting up the service itself is ops' area [21:36:19] I think we only have standard deploy for nodejs [21:36:36] the MW extension part in JS/PHP would have to conform to all the usual requirements [21:36:48] all others are pretty much "do your own puppet/scap3" [21:36:48] deploying to WMF prod requires at some point getting approval from releng and techops [21:36:59] hypothetical for discussion: a new labs service written in an Esolang. (e.g. BrainFNORD) [21:37:17] quiddity, E_GOODFORTHEM [21:37:21] for node.js we also have service-runner, which is the in house service framework [21:37:23] but the question is: how many volunterrs would be writing non-toollabs services? [21:37:50] not many I'd imagine, most volunteers I've seen writing code stick to their gadgets and labs tools [21:38:12] right. Or patching existing ones (like pywikibot) [21:38:24] is that by design? [21:38:35] pywikibot is a python bot framework, rather than a service, right? [21:38:49] getting completely new code into production is a non-trivial process but for good reasons I think [21:38:50] robla, no I think most useful tools are supposed to graduate from labs eventually, theoretically [21:38:58] given how many stakeholders one needs to gather to approve/deploy new service, I'd say it's both design and de facto [21:39:08] even getting a new PHP extension deployed on WMF is non-trivial [21:39:25] true [21:39:50] which leads to kitchen-sink extensions like mobilefrontend [21:40:52] Krenair: right, but that eventually leads to bots which are kind of services... [21:41:02] from my personal experience the 2 big hurdles were security review and puppet automation [21:42:15] because it's easier to put extra features into an existing extension with far less approval than it takes to deploy a new extension? [21:42:18] yeah I think with puppets we don't have much choice besides a) learn puppet or b) bribe somebody who knows puppet [21:42:19] both really due to limited revewer resources. [21:42:40] Krenair: yes. there is no second or third or fourth security review [21:42:51] it sucks, but I can say from experience that it sucks much less than it did 3 years ago [21:43:06] Is it a problem of getting puppet code written, or getting into onto the actual production puppetmasters? [21:43:30] for my puppet is was getting it reviewed and merged [21:43:45] SMalyshev, you're probably right wrt stakeholders btw, I was thinking from the labs perspective [21:44:15] it's not simple to test puppet manifests [21:44:29] I think the ops team usually deploys them untested (except for a lint check) [21:44:56] so to make sure things work, they are limited to staring at the code really hard [21:45:01] TimStarling: yeah that too. even if your build own puppetmaster (non-trivial) still labs and prod differ a lot [21:46:34] they said to me "you can build your own puppetmaster" and I said "where is the puppetmaster *you* use to test your changes? can I use that one?" [21:46:45] and it transpired that there wasn't one [21:47:04] heh [21:47:31] I've tried to talk folks into testing in deployment-prep more often but... yeah [21:47:51] * robla looks at https://www.mediawiki.org/wiki/Puppet and gets sad [21:48:51] robla: https://wikitech.wikimedia.org/wiki/Puppet probably :) [21:48:55] it was empty, and is ripe for redirecting. [21:49:26] looks like still ripe for redirecting to wikitech :) [21:49:42] done [21:49:50] robla: https://wikitech.wikimedia.org/wiki/Puppet [21:50:04] and https://wikitech.wikimedia.org/wiki/Puppet_coding [21:50:49] knowing what goes on mw.o and what goes on wikitech and what goes on meta is still a challenge for me [21:51:14] mediawiki.org only if it's mediawiki code [21:51:20] meta probably not for technical things [21:51:29] bd808: I'm guessing it's a challenger for any newcomer to our codebase [21:51:30] wikitech for pretty much anything wikimedia-related that's technical [21:51:59] Krenair: but mw.o has all of the WMF teams and projects which could be anything [21:52:09] bd808, yes but should mw.o have all of that? [21:52:24] Krenair, yes, but that only works if one doesn't mind the SUL issue (notmywiki gets even worse when people have to create a new account just to contribute) [21:52:24] and there are quire a few technical things on meta like quarry docs [21:52:32] for a lot of projects I have written a page on each wiki [21:52:43] those things need to be tagged for moving off of mediawiki.org but I've never got around to it [21:52:43] they have a different audience [21:53:15] for mw.org I write for external users, basically public-facing source code documentation [21:53:26] for wikitech I write notes for the ops team [21:53:26] quiddity, if we're talking about people that want to contribute to our software they should probably have gerrit access, and this requires them to have a wikitech account [21:54:11] contributions can be in the form of user-feedback, and other non-technical guises! ;-) [21:54:35] someday wikitech will be a SUL wiki [21:54:49] gibe me another 9-12 months [21:55:44] this has been a really great conversation, thanks everyone! Lemme look up the link to the thing we'll be suggesting for next week.... [21:55:58] Thanks, All! [21:57:10] next week's Phab event is https://phabricator.wikimedia.org/E228 and https://phabricator.wikimedia.org/T589 is what we're tentatively planning on [21:58:42] I dunno, was it useful to other people? I feel like I've mostly been talking about problems with our existing situation [21:58:47] Maybe that's useful, maybe not [21:59:10] Krenair: it was very useful to me to know what edits to make to mediawiki.org, so I appreciated it [22:00:36] thanks TimStarling for chairing/meetbot running :-) [22:00:50] #endmeeting [22:00:50] Meeting ended Wed Jul 6 22:00:50 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:00:51] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-07-06-21.02.html [22:00:51] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-07-06-21.02.txt [22:00:51] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-07-06-21.02.wiki [22:00:51] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-07-06-21.02.log.html