[14:43:25] Hello wolliff! [14:59:03] Hello everyone! This is Katy and I'm with a few other FDC staff--we're holding office hours here over the next hour about the APG proposal form. [14:59:08] And proposal process. [14:59:13] We'll get started in just a minute. [14:59:29] Hello KatyLove and others [15:00:13] Alrighty! It's time to get started. [15:00:18] Tick tock :) [15:00:28] Hello, everybody! [15:00:36] I am joined by wolliff, hi there! [15:00:47] Are there any members of the Funds Dissemination Committee here? [15:01:12] Hello, Katy! [15:01:14] Are there any APG applicants in the room? [15:01:19] Hi wolliff ! Funny seeing you here! [15:01:26] I saw SRientjes_ [15:01:36] Welcome, Sandra! [15:01:39] and michal__! [15:01:47] Nice to IR SEE you ;) [15:01:49] Waves to all [15:01:53] Waves all around [15:02:04] Hello, Garfield! [15:02:06] And a warm welcome to Garfield_ ! [15:02:27] So we are here right now to talk about the annual plan grant proposal process. [15:02:27] Garfield, you missed my terrible pun. I will make another soon. Don't worry. [15:02:34] phew [15:02:36] Yay! [15:02:51] Good Morning [15:02:59] As you may know, eligible Wikimedia organizations apply to the Funds Dissemination committee (the FDC) [15:03:02] for funds for the annual plans. [15:03:12] wolliff just published the final eligibility table a few days ago [15:03:21] so now we know who is eligible to apply for the program. [15:03:25] wolliff - could you share the link? [15:03:26] With much help from Janice! [15:03:31] Yes, just a moment. [15:03:32] Yes, thank you Janice too! [15:04:06] In the mean time, organizations who are interested in these grants (annual plan grants) are working hard on their proposals [15:04:07] http://meta.wikimedia.org/wiki/Grants:APG/Eligibility/2014-2015_round1 [15:04:17] these proposals will be submitted to the FDC by October 1 - close of business UTC time [15:04:25] thanks wolliff ! [15:04:41] These proposals can be a lot of work [15:04:46] scratch that [15:04:49] These proposals are a lot of work [15:05:06] for the organizations, their boards and staff and communities [15:05:18] And especially their EDs [15:05:27] :) SRientjes_ - true!! [15:05:40] Based on feedback from these applicants, as well as from the Advisory Group that did an evaluation of the first two years of the FDC [15:05:50] We streamlined and tightened the proposal form even more. [15:06:10] We hope it will be more light weight for applicants, as we cut a fair number of questions. But we know it is still tough, since the deadline is in a few weeks time. [15:06:34] So we are here today to hang out with anyone who is here and interested in the APG program generally, but most specifically to answer questions about the proposal process. [15:06:52] Garfield_ can help too with any specific questions about the finances and budgeting [15:07:12] And by the way--someone has kindly pointed out I miswrote the deadline above [15:07:19] Thank you for flagging that! [15:07:30] Happy to assist as needed. [15:07:40] I was wrong. The deadline is actually end of day (23:59) UTC time on Oct 1. [15:07:45] So there, a few bonus hours for everyone! [15:08:18] wolliff or Garfield_ -- any introductory comments you want to make? [15:08:19] BONUS TIME to work on the proposal until midnight. [15:08:26] what fun! [15:08:30] We hope that doesn't happen. [15:08:51] Katy, I like the new simplified proposal form. Great job with that! [15:09:54] Alrighty--so, let's see if there are any burning questions out there [15:10:21] +1 to liking the new form. I like the fact that the form now focusses really on the work for the coming year, and its expected outcomes [15:10:44] That's good to hear. [15:10:53] As to questions [15:11:37] I was focussing very much on being as SMART as possible. But in the last mail, Katy suggested focussing on key objectives to illustrate the narrative. [15:11:53] That made me a bit confused. How much detail is expected/appreciated? [15:12:20] And I think we have our colleague janstee here to potentially help with questions too on the SMART objectives! [15:12:53] SRientjes_ - we are looking for 2-3 objectives per goal. [15:13:20] The FDC will want details to understand the nature of the program [15:13:55] But in drafting the objectives, having a tight SMART objective will help keep is focused. [15:14:19] janstee has suggested that you may want to keep track of and regularly measure more than what you put in the SMART objective (and in the proposal) [15:15:36] but it's a good question about the level of detail [15:16:14] Yes, we are trying to help organizations provide more focused information rather than very long proposals with a lot of detail. [15:16:17] The next year's annual plan (which is submitted as part of the proposal) and the progress reports to date on relevant programs will also help provide context [15:16:29] If some details are important, we encourage you to include them in supplementary documents, for example. [15:16:44] We really want the proposal form to be about the impact you will achieve, and we want to understand how you plan to achieve it. [15:16:57] Our annual plan is in Dutch. Is a translation required? [15:17:09] Yes, we will need an English version or summary. [15:18:17] We are talking about the annual PLAN? Not the annual report? [15:18:50] Yes. [15:22:02] If including the annual plan in English will be a challenge--please let us know [15:22:49] Yes, we can help translate or figure out a solution with machine translation. We just need to make sure the FDC can read your plan somehow. [15:22:59] Not so much a challenge as a surprise [15:23:01] The annual plan is an important part of the proposal. [15:23:22] I understand - but I don't think we ever submitted a translation before [15:23:43] Sandra, I don't think the proposal form specifies that it should be in English, so we can certainly be flexible about that. As long as we can decipher the plan somehow :) [15:24:21] Dutch is a fairly straightforward language ;) [15:24:32] That's true, it's practically in English!! [15:27:10] Thanks for the good questions, SRientjes_ [15:27:17] Do you or any others have other questions? [15:27:21] Thanks for the answers! [15:28:09] I sent a link to our draft application - if you or Jaime have the chance I would appreciate feedback on the general direction [15:28:53] Especially the level of detail we talked about before [15:30:42] Yes--thanks for the SRientjes_ ! [15:30:50] It's a really helpful way to see what you're working through [15:31:08] And we have been reading it and working through it --will come back to you in the next two days with comments. [15:31:12] Thanks for sharing so much! [15:31:43] Looking forward to your comments (I think....) [15:33:27] I don't have any more questions. [15:34:01] It was really nice to chat - and useful! [15:34:08] It's always nice to chat with you SRientjes_ [15:34:11] :) [15:34:23] Another thing for us all to think about: [15:34:28] Awesome. Thanks for the questions about the annual plan, by the way. We realize that's a point that needs clarity as it may have been confusing in the past. [15:34:51] As we wean the proposal form and cut it down a bit to make it easier for applicants to fill out, we are in need of the annual plan for the coming year to provide that important background, context, planning info [15:35:06] So please do make sure you (whoever sees this!) do submit an annual plan for 2015 [15:35:45] That makes sense. Practical problem on our side: the APG application is based on the annual plan which has to be approved by the members [15:36:07] Right [15:36:10] We moved forward our AGM from november to mid september to fit the APG process [15:36:11] This is a common challenge! :) [15:36:19] OK [15:36:27] If you can give us a draft, that will work too [15:36:35] If we have to have room from translation, everything is going to become really tight! [15:36:46] But we will find a way. [15:37:32] We just did a quick review of how it's worked in the past [15:37:50] Most applicants, though not all, submit annual plans for the coming year [15:37:58] I can definitely link to approved Annual Plan in Dutch before Oct 1, and then provide link to translation later? [15:38:07] Yes, that would work [15:38:18] Please make sure it's easy for Google translate to translate [15:38:27] Because we would use that in the mean time while we brush up on our Dutch [15:38:31] ;) [15:38:38] So wiki text over PDF would be preferable [15:38:53] Katy, Dutch is like the same as English. [15:38:57] Yes, good point about the format. [15:39:03] I translate dutch to english via google translate occasionally to amuse myself. It can be really funny! ;) [15:39:08] It would be helpful to have a text version available on Wiki. [15:39:34] It's great for poems! [15:39:41] Word document? [15:39:55] Just Wiki text? [15:40:17] Is a word doc easier for you? [15:40:56] Yes, I came to this movement late in life. Everything is easier than wiki-text. [15:42:09] haha! [15:42:29] So long as it's not a PDF it will be OK for us to use Google translate [15:42:48] Sandra, have you used libre office before? [15:42:58] And that document should be posted publicly so anyone could easily translate it [15:43:00] Did you know you can save office documents as wiki text? [15:43:22] And, yes, as Katy says, that's OK. Just an FYI, in case that ever makes life easier for you ;) [15:44:27] I am willing to learn about libre office and how to save docs as wiki text. I already use excel to wiki. [15:44:49] Cool! [15:44:53] Yes, excel to Wiki is great! [15:45:12] Anyway, I will show you another time. It is a cool feature of libre office. [15:45:41] That would be great wolliff [15:46:55] That sounds fun [15:47:38] Alrighty--are there other questions? [15:47:54] Not from me! [15:48:02] Okey dokey! [15:48:26] Thanks for joining us, Sandra! [15:48:44] for anyone interested in the annual plan grants program, please check out our page with links to everything you could want to know about! https://meta.wikimedia.org/wiki/Grants:APG/Calendar [15:48:47] Bye - see you next time! [15:48:56] From that page, click on anything to navigate around and learn more about various steps [15:50:00] Garfield_ any closing thoughts? wolliff any closing thoughts? :) [15:50:27] Just let us know if you need any assistance. [15:50:58] I need assistance, Garfield_ --I need a chocolate. [15:51:02] Thanks Garfield_ I will! [15:51:31] Anyone reading this later, please don't hesitate to reach out via FDCsupport@wikimedia.org or reach out to any of us directly [15:51:41] We can easily set up an individual call / chat / Hangout / IRC -- whatever you prefer [15:51:58] I know that there have been a few questions that came in a few hours ago while I was sleeping and we'll respond to those soon!: ) [15:52:19] So with no further ado, let me thank everyone who joined me here in this cozy IRC chat room! [15:52:30] Bye, Katy. Thanks for hosting. [15:52:31] And let me thank, too, all of you working hard on proposals right now [15:53:01] And I would like to thank the Academy! [15:53:28] :) [15:53:40] cheers, y'all! [15:53:58] Join us next time… on APG IRC office hours… with our host… Kaaaaaaaaty Love. [19:59:05] Eloquence: does communication team do office hours? I have some ideas i would like to run by them. Can alway mail, but live chat is better than back and forth [21:00:44] hello [21:01:16] #startmeeting RFC meeting | https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:01:16] Meeting started Wed Sep 17 21:01:16 2014 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:01:17] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:01:17] The meeting name has been set to 'rfc_meeting___https___meta_wikimedia_org_wiki_irc_office_hours___please_note__channel_is_logged_and_publicly_posted__do_not_remove_this_note_____logs__http___bots_wmflabs_org__wm_bot_logs__23wikimedia_office_' [21:01:37] #topic RFC meeting | https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:01:56] * aude waves :) [21:02:32] no agenda was announced for today's meeting, so we're going to have a triage meeting in this time slot, and we're going to try to schedule a normal RFC meeting for this time tomorrow [21:02:42] whee [21:02:47] tomorrow we would like to discuss https://www.mediawiki.org/wiki/Requests_for_comment/Linker_refactor [21:02:51] if aude is available [21:03:08] sounds good [21:03:25] aude: were you expecting to talk about it today, and if so, how did you find out? :-) [21:03:37] robla: i was here last week [21:03:40] when it was announced [21:03:55] tomorrow is ok and maybe we can send a mail letting people know [21:04:10] ah, ok, so it wasn't a complete surprise, but you agree more publicity would be better. [21:04:17] yep [21:04:19] ah good :D [21:04:21] organizing is hard :D [21:04:32] sumanah used to help with this but no more :( [21:05:03] the other one we want to discuss tomorrow is https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Page_protection_as_a_component [21:05:16] rather https://www.mediawiki.org/wiki/Requests_for_comment/Page_protection_as_a_component [21:06:13] also a good topic [21:06:25] i’m sure there’s some folks interested in such things [21:06:31] so let’s make sure to pass it around yeah [21:07:07] i can see implications with wikidata and page protection [21:07:11] the author is Adam Wight, who has a daily standup scheduled at that time, but hopefully he can move that [21:07:16] so want to be around for that [21:07:36] awight: ^ [21:07:56] all right :D [21:08:51] TimStarling: oof, I though that was today somehow. I won't be able to make it tomorrow, already scheduling babysitter around a demo I have to give for a side job at this time [21:09:30] yeah, has someone been secretly reading our committee minutes and announcing meetings? because we didn't know you two had been contacted about this [21:09:51] heh [21:09:54] hehe. Yeah I think I got wind from something mentioned during last week's meeting [21:09:57] we must have pasted something last week :D [21:10:20] * awight runs the IRC logs over to the NY Times office :p [21:10:34] but it didn’t make it to email iirc [21:10:40] “if it’s not on list it didn’t happen” [21:10:49] can we just talk about it now then? [21:11:03] fine by me [21:11:04] works for me if y’alla re ready [21:11:28] #topic Page protection as a component | RFC meeting | https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:11:35] #link https://www.mediawiki.org/wiki/Requests_for_comment/Page_protection_as_a_component [21:11:47] To summarize the [page] protection as a component thing, I noticed that there's a lot of security logic mixed in among classes which have other responsibilities. [21:12:11] *nod* that’s the result of creeping featurism instead of solid planning :) [21:12:21] understatement [21:12:21] I took a few dead-ends in exploring this, but I think the correct way to proceed is to do security via hooks. [21:13:12] I would suggest consolidating the security code into a new directory, includes/security [21:13:23] awight: any exploration of read-restrictions as well as write-restrictions in there? [21:13:29] yeah [21:13:32] i ask as it’s a popular topic among third-party users especially [21:13:46] you mean non-security code would call the hooks, and includes/security would register handlers for them? [21:13:52] yes [21:14:12] I didn't go so far as to think about a better internal and external interface than we have now... but that is a thing that should happen. [21:14:32] I'm not a big fan of hooks, generally speaking [21:14:38] *nod* i’d kind of prefer a ‘security clearinghouse’/‘firewall’-y class with the interfaces [21:14:44] leave hooks as an implementation detail for that [21:14:47] but that’s just a general preference [21:14:52] that sounds good [21:15:04] even for extensions, I have introduced a fair few non-hook interfaces [21:15:05] yeah, internal stuff doesn't seem to utilize hooks, which is fine. [21:15:32] Hooks are a PITA when you care about ordering. [21:15:40] That's really my only beef with them. [21:16:45] I think OOP interfaces like FileRepo and AuthUser are better [21:18:10] you could theoretically use a hook sequence like an ACL sequence [21:18:55] Are there any extensions that do security in a way we'd like to adopt for the general case? [21:18:58] but like you say, it is difficult to control the order [21:19:11] It sounds like componentization is an easy sell... [21:19:26] So the remaining questions are perhaps about granularity and choice of interface. [21:20:25] i’d like the interface to be amenable to unit testing at least :) [21:20:31] *yes* [21:20:40] so we can mock up a bunch of actions, run them through defined ACL configs, and make sure they act as expected [21:20:42] CheckAction -- we basically have that already don't we? [21:20:45] without the rest of the intrastructure [21:21:21] reading from [21:21:24] https://www.mediawiki.org/wiki/Requests_for_comment/Page_protection_as_a_component/Componentization [21:21:37] do we also want to think about looking at blocking/other restrictions/permissions things which are also related to protection? or out of scope for this rfc? [21:21:42] it would be nice if permissions/protection could be more fine-grained than the title level (e.g. depending on content type) [21:21:58] legoktm: i think they’re very related [21:22:11] for wikidata use-case, we potentially might want stuff like labels to be protectable while not the entire item [21:22:14] a block is essentially a temporary (or permanent) modification to a user’s permissions [21:22:34] yeah, I know there are a few rfcs relate to refactoring or changing how those things work, /me finds [21:22:56] aude: *nod* protection-by-action i guess takes care of that sorta thing? [21:23:06] maybe [21:23:18] There's also query filtering. [21:23:20] also, cross-wiki stuff [21:23:25] like images [21:23:53] this may take a while to work out all the details yeah :D [21:23:59] if a page on enwiki is protected, then it's a back door to vandalise images on commons, unless the commons image is protected [21:24:13] potentially same thing with wikidata [21:24:19] * brion hmms cross-wiki cascading protection? [21:24:23] erp. [21:24:28] then when unprotected, page can be purged [21:24:36] or something/how :) [21:24:46] we already have the getUserPermissionsErrors hook, which has parameters: Title, User, action, result [21:25:07] anyway, whatever is flexible and might allow these use cases :) [21:25:11] which is pretty similar to the proposed CheckAction [21:26:13] TimStarling: I think in my (deprecated) use case, I wanted to have the ability to grant access via hook, but the current getUserPermissions hook only allows denying access. [21:26:47] But like I say, I'm not attached to that idea any more. Building denials using OR is probably the most correct. [21:26:51] we have a hook for allowing access now, it's in use on enwp. [21:27:03] (TitleQuickPermissions) [21:27:26] ok, so that need does exist [21:28:44] awight: have you read all the permissions code in Title? [21:28:48] there is a lot of it [21:29:08] TimStarling: yes, but 2 years ago. I stripped it all out and hook-ified for fun... [21:29:48] There certainly is a ton, and some of it is tough to isolate in its own class. [21:30:19] What I ended up doing was trying to move each protection algorithm into its own class, so TitleProtection, PageCreationProtection, etc. [21:30:22] something like that. [21:32:29] anyway... [21:32:45] in this RFC I don't see "refactor the whole permissions system" on the todo list [21:32:49] baahaha [21:33:14] I'm not sure if I agree with moving page protection out of core, I think in core people actually want more specific and granular permissions things which protection is the base for. [21:33:15] I think the first step was to see what the consensus is [21:33:18] I thought we were talking about introducing a set of classes for page protection, which the existing relevant points in Title etc. would call [21:33:33] exactly. [21:33:42] and then adding desired features to the resulting class [21:34:34] What I was suggesting a minute ago was, we should have a lightweight and pluggable interface for security things, then specific algorithms such as title creation bans should be implemented in a small component. [21:34:54] This can all live in core, or in a default-bundled extension. [21:35:33] well, I'm not approving that today [21:35:44] :) that is wise [21:36:14] baby steps :D [21:36:59] but I think I can approve implementation of a protection component, subject to code review [21:37:01] brion, you agree? [21:37:08] TimStarling: i agree [21:37:31] #agreed RFC "Page protection as a component" approved [21:37:41] \o/ [21:38:10] What do you think about the first step? My previous approach was to simply strip out the security stuff, and call it as-is. But it might be more productive to design an interface and move existing code to behind that. [21:38:16] to be clear, this is as a new component in core or as an extension? [21:38:19] Sounds like we differ on this, however? [21:38:22] core [21:38:45] ok, +1 then :) [21:38:50] awight: i know it's tough but also put in place tests for existing code, as possible [21:39:02] must-have. [21:39:06] then as stuff gets moved, more confidence about not causing regressions [21:39:38] awight: not sure what you mean by "strip out" [21:40:20] TimStarling: This is not the greatest example, but https://gerrit.wikimedia.org/r/#/c/23999/4/includes/Title.php,unified [21:40:47] This moves all Title security to live behind an ad-hoc hook CheckActionPermissions, which supplies all the variables that previous code used. [21:41:06] It lets me copy + paste the code very literally, which makes the chance of regressions a bit lower. [21:41:28] The alternative would be to intentionally design an interface, then refactor the security code behind that as we move it into a component. [21:41:41] Saying this out loud, I almost prefer the simplistic first option. [21:42:24] Then at least, we can take inventory of what we have, and maybe this will inform designing an interface in a later phase of development. [21:43:07] no, I think you would have to leave b/c interfaces in there for public methods [21:43:17] and I don't think hooks should be used in the core [21:43:34] agreed on both [21:44:39] Yeah, adding a new external interface is probably the very last thing to do, cos it's so irrevokable. [21:45:46] Well, I'm clear on the next iteration of this project, at least. [21:45:52] good [21:46:01] yeah, thanks for your time, all! [21:46:13] any other topics for discussion? [21:46:54] * aude happy to see this move forward [21:46:59] thanks awight [21:47:17] aude: of course! Don't mind if I ping you about wikidata use cases... [21:47:21] shall we do aude's RFC only tomorrow? [21:47:44] I don't have a formal RfC written up yet, but if no one has anything else and we still have some time today, I'd like to talk about some Config things we're working on and ask for some feedback? [21:48:11] sure [21:48:51] awight: sure, anytime [21:49:21] #topic Ongoing Config work | RFC meeting | https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:49:47] so https://gerrit.wikimedia.org/r/#/c/153541/ is the implementation of "MultiConfig" which basically provides fallback logic for Config objects, the eventual idea is that we could turn DefaultSettings.php into a HashConfig (array basically) at the bottom of the MultiConfig, and have other things on top [21:50:16] and we would be able to use the same principle for wikifarm config, have a general WikimediaConfig, then a WikisourceConfig, and then a EnglishWikisourceConfig on the top [21:50:43] interesting [21:51:00] and these are merged on access? [21:51:35] like how SiteConfiguration handles + arrays? not in the current implementation [21:52:11] I mean MultiConfig::get() checks each array [21:52:35] is that then called instead of global access? [21:52:40] oh, yes [21:53:03] so the 'main' config type in $wgConfigRegistry would be an instance of MultiConfig [21:53:46] how would you migrate to this? [21:54:40] well right now we already have started migrating code in core (and a few extensions) to use the current 'main' config, which is just a wrapper around $GLOBALS, the typical way to access it is RequestContext::getConfig() [21:55:01] https://gerrit.wikimedia.org/r/#/q/project:mediawiki/core+topic:conf,n,z [21:55:38] nice [21:57:15] so the first step to using MultiConfig would be to convert DefaultSettings into a HashConfig, and then on top have a GlobalVarConfig so everything is still in $GLOBALS for the other things that still need it. We'd also need a HashConfig->extractToGlobals() so DefaultSettings.php is still available as global variables [21:57:54] how would things like $wgHooks and $wgResourceModules work? [21:58:33] and extension configuration generally? [21:58:49] I want to take care of those with the extension registration RfC: https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration (which I haven't had much time to work on lately :/) [22:00:55] we should probably talk about that some time [22:01:01] so ideally wfLoadExtension('Foo') would register the resource loader modules directly with the ResourceLoader instance that OutputPage uses, and it never has to go into $wgResourceModules [22:01:25] yeah, I need to work on some of the caching things, but the concept is mostly done [22:01:42] it looks good [22:02:08] right, I see there was an IRC meeting that I wasn't in [22:02:48] 19:01:26 I don't see Brion around, and of course it's the weekend for Tim and evening for Mark, but I hope we will still have useful things to say about Kunal's proposal :-) [22:03:59] #endmeeting [22:03:59] Meeting ended Wed Sep 17 22:03:59 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:03:59] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-09-17-21.01.html [22:03:59] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-09-17-21.01.txt [22:03:59] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-09-17-21.01.wiki [22:04:00] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-09-17-21.01.log.html [22:21:32] * DanielK_WMDE_ blinks