User:SPage (WMF)/ReleaseManagementRFP IRC log

From mediawiki.org

This is me trying to make something nice out of http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20130620.txt

The package irclog2html does a good job with it, but it generates HTML referring to a CSS file, not wiki markup.

poem tag[edit]

Try poem tag:

[16:51:10] * hexmode waves at mglaser �
[16:51:17] <hexmode> and the rest of you, too!
[16:55:25] <mglaser> hi there :)
[16:55:44] <Emufarmers> Hello
[16:55:55] <legoktm> hi
[16:58:23] <Nikerabbit> uga
[16:58:58] * marktraceur kicks James_F�
[16:59:03] <marktraceur> Not allowed in here
[16:59:10] <hexmode> heh
[16:59:42] * James_F grins.�
[17:00:24] <hexmode> and it begins
[17:00:39] <greg-g> Hello!
[17:00:44] <greg-g> Thanks for the topic change, marktraceur
[17:00:53] <marktraceur> greg-g: I can be your bot! :)
[17:00:56] <greg-g> So, let's just kick this off.
[17:01:01] <greg-g> marktraceur: #startmeeting
[17:01:12] <mglaser>  :)
[17:01:22] <greg-g> Welcome, all to the office hours for the MediaWiki Release Management RFP
[17:01:36] <bawolff> greg-g: Perhaps send a note to #mediawiki and #wikimedia-dev to remind people who may have forgot
[17:01:44] <greg-g> we have hexmode and mglaser here from one of the proposals, is anyone here from the EIJL proposal?
[17:01:48] <legoktm> hey
[17:02:00] <greg-g> hello legoktm ! thanks for coming
[17:02:00] <legoktm> Emufarmers, Isarra, ashley and myself :)
[17:02:01] <Emufarmers> We have E, I, J, and L
[17:02:15] <greg-g> Great, a full house.
[17:02:34] <greg-g> So, I want to first open this up to others (ie: not me) to ask questions.
[17:03:07] <greg-g> How about we start with hexmode / mglaser's proposal: https://www.mediawiki.org/wiki/Release_Management_RFP/NicheWork_and_Hallo_Welt!
[17:03:31] * hexmode is ready to answer ANYTHING�
[17:03:33] <greg-g> There's been some discussion on the talk page for theirs, if people want to take a look: https://www.mediawiki.org/wiki/Talk:Release_Management_RFP/NicheWork_and_Hallo_Welt!
[17:03:58] <bawolff> Q: Two people with Mark-esque names, are you worried there will be confusion?
[17:04:08] <greg-g> I second the question.
[17:04:12] * bawolff notes this is what you get when you say ask anything�
[17:04:29] <mglaser> If nothing helps, we use numbers :)
[17:04:30] <marktraceur> bawolff: All marks are actually the same person in different costumes
[17:04:30] <robla> I don't think we could have a true Wikimedia initiative without name confusion
[17:04:35] <hexmode> bawolff: no. I'm "hexmode" online mostly. And our on-wiki names are distinct
[17:04:42] <marktraceur> It's an elaborate plan to get more candy on Halloween.
[17:04:54] <greg-g> marktraceur: quite elaborate.
[17:05:11] <bawolff> marktraceur: OMG its true, I've never seen them in the same (physical) room together
[17:05:21] <mglaser> and we both have beards ;)
[17:05:40] <greg-g> I don't want to make you two rehash your proposal here, but, we just got out of a discussion that deals with making life easier for extension owners/authors, what are you thoughts on that?
[17:05:44] <hexmode> you should have been at AMS -- we were both there on Friday.
[17:06:34] <James_F> Q: For those of us who do/used to run internal corporate MediaWiki instances (1.12, yay), you do think MW should move towards a more "enterprise"-like wiki model (e.g. granular security; files 'attached' to pages/namespaces), and if so, how do you see this happening/
[17:06:41] <greg-g> (continued...) I see it mentioned a few times in your prososal, and I like the general idea, just curious what specifcs you were thinking?
[17:07:40] * robla starts humming elevator music  :-)�
[17:07:46] <greg-g> <audio src="jeopardy_theme.ogg">
[17:07:52] <mglaser> greg-g: first of all, work on extension versioning.
[17:08:19] <mglaser> It is not very clear which extension work with which MediaWiki Versions.
[17:08:35] <mglaser> and you can't expect tarball users to update on every MW release
[17:09:01] <greg-g> mglaser: completely. I've seen some use of Composer, were you thinking of going that route?
[17:09:49] <hexmode> James_F: So with people running 1.11 or 1.12, what they want is some stability and don't want to worry about upgrading every six months.
[17:10:22] <hexmode> James_F: first step is having an LTS that will be supported for a couple of years
[17:10:24] <bawolff> mglaser: How do you intend to work on that issue? I assume a lot of extension versioning would have to fall on the shoulders of extension maintainers. How do you plan to convince them to do that
[17:10:26] <mglaser> Yes, that's an option. I like relying on existing models instead of reinventing the wheel ourselves :)
[17:10:39] <greg-g> mglaser: good. :)
[17:10:40] <hexmode> James_F: and a clear path for support and upgrade
[17:11:29] <mglaser> bawolff, take wordpress for example. They have crowdsourced this: for a given combination of WP Version and Plugin Version, you can indicate whether this works for you.
[17:11:46] <hexmode> James_F: this ties into what mglaser is saying about extensions, too. We haven't really discussed the LTS and extensions, but it would be good to get developers on-board with supporting the LTS in their extensions.
[17:12:03] <Nikerabbit> how often would there be LTS releases?
[17:12:10] <mglaser> when some people have done so, you get a good impression on what works
[17:13:03] <Nikerabbit> usually there is some overlap time where people can migrate to the next LTS version
[17:13:10] <hexmode> Nikerabbit: so https://www.mediawiki.org/wiki/Version_lifecycle shows every two years with an LTS getting 3 years of support. I think that is right
[17:13:24] <hexmode> a year of overlap seems reasonable
[17:13:40] <James_F> hexmode: That page should probably be marked "speculative". :-)
[17:13:44] <bawolff> How do you feel LTS has been going so far?
[17:13:57] <mglaser> Also, to make it easier for extension developers, we need to find a way to handle breaking changes. Currently, these keep some extension maintainers away from updating their extensions. Not saying there should be no breaking changes, but they need to be communicated and documented very clearly, altogether with an upgrade path
[17:14:12] <hexmode> James_F: sure, but it is mostly my speculation ;)
[17:14:18] * James_F grins.�
[17:14:56] <Nikerabbit> perhaps one important thing would be to announce the upcoming LTS releases before people break support for them in extensions (like I did)
[17:15:14] <bawolff> mglaser: I think any discussion on avoiding breaking changes, should have a concrete definition of what constitutes a breaking change
[17:15:28] <hexmode> bawolff: I haven't gotten backports made that I want to get made. That has been mostly a time issue right now. Hopefully with this proposal, I would have more time since I know my time would be compensated.
[17:15:38] <greg-g> Nikerabbit: are you thinking an overall roadmap/plan for the next LTS that is in place ~6 months in advance (or something?)?
[17:15:52] <hexmode> bawolff: but I'm happy with the security patches
[17:15:55] <bawolff> People do weird things in extensions. Sometimes a change that doesn't look breaking, can break somebodies weird hack of an extension
[17:16:08] <Nikerabbit> greg-g: just raising awareness, many people didn't/don't know that 1.19 has been nominated to be LTS release
[17:16:14] * greg-g nods�
[17:16:43] <mglaser> bawolff, I agree. But there have been some major refactorings, eg ResourceLoader in the past. And I guess, Contenthandler might be the next candidate.
[17:16:47] <James_F> Nikerabbit: Also, the problem is that it sets expectations for MW extensions that their authors don't necessarily want / have the ability to support.
[17:16:50] <hexmode> Nikerabbit: how could we raise awareness? I've done everything short of a blog post on the wmf blog.
[17:16:56] <mglaser> that is to say, ResourceLoader is really well documented.
[17:17:05] <James_F> hexmode: If you want a WMF blog post, just shout. :-)
[17:17:34] <Nikerabbit> hexmode: good question I don't have good suggestions
[17:17:42] <Isarra> Has there been anything on the release mailing list? Seems like one of the few things besides actual releases that would be relevant there.
[17:17:42] <robla> a lot of our hooks give access to large internal objects (e.g. User, Title) that it's harder to maintain backwards compatibility with, so we should be careful what we expose/encourage in our hooks
[17:18:05] <hexmode> Isarra: what do you mean?
[17:18:24] <mglaser> We might have a definition of "active extensions", where one requirement is to follow extensions-l or similar in order to be able to reach out to the developers
[17:18:30] <greg-g> (office keeping: I want to transition explicitly over to EIJL's proposal at :30, and I also want to give the proposers themselves time to ask us/the community questions, so I'll open it up for hexmode / mglaser to ask questions at ~ :20ish)
[17:18:45] <Isarra> There is a mailing list specifically for announcing releases so sysadmins know when to update - they would probably want to know if there is also now an LTS one.
[17:18:48] <hexmode> I mentioned the LTS in the 1.20 release announcement, but maybe that should be repeated.
[17:19:01] <Isarra> Yeah, I missed that.
[17:19:07] <hexmode> Isarra: good point
[17:19:21] <Isarra> Lumping stuff together, people tend to just see the first bits.
[17:19:22] <hexmode> todo: more visibility for the LTS
[17:19:56] <mglaser> One question is: would it be a good idea to *require* extension developers write some kind of tests?
[17:20:15] <hexmode> also announcements: I think Tim is the only person right now who can turn off emerg mod on the -announcments list
[17:20:20] <bawolff> mglaser: And what would be the consequences of if they didn't?
[17:20:26] <Nikerabbit> have it requirement to reach some sort of badge or quality level
[17:20:32] <mglaser> and then notify them if their extension is about to break in the next release
[17:20:40] <greg-g> hexmode: we can setup people with posting access to it as needed.
[17:20:57] <Isarra> You need a better extension framework before you can demand tests. Do you have plans for developing anything of that sort?
[17:21:04] <hexmode> badge/quality marking on-wiki for people with tests
[17:21:06] <bawolff> Some sort of test to ensure at the very least that the extension doesn't fatal out immediately upon load would be good
[17:21:09] <mglaser> bawolff: there could be a category "Extensions following our QA guidelines"
[17:21:23] <greg-g> so, before we switch to you all asking us/others questions: I'm curious on your thoguhts about KickStarter as that can sometimes be a huge timesink/failure if done incorrectly. What are you generally thoughts on that?
[17:21:27] <bawolff> I imagine part of the problem would be not all tests are created equal
[17:21:45] <bawolff> Its easy to make non-useful tests that pass no matter how broken the extension becomes
[17:22:01] <hexmode> greg-g: I suggested that, but I've seen very suprising successes with it
[17:22:02] <bawolff> Isarra: What do you feel is wrong with the extension framework currently?
[17:22:22] <hexmode> greg-g: if you know of a best-practices for kickstarter, I'm interested
[17:22:22] <mglaser> greg-g: I think, any Kickstarter campaign has to be prepared professionally. I guess, we might seek some external help there.
[17:22:48] <mglaser> From all I can see, this really makes a difference.
[17:23:03] <bawolff> Isarra: Or I guess we should get to that when the office hour switches over to your proposal
[17:23:12] <greg-g> Gotcha. Let's explore that more as needed, I'll ask some on the talk: page
[17:23:32] <greg-g> but, it is now :23, any questions from hexmode / mglaser of the community/us?
[17:23:48] <hexmode> what do you guys think we missed?
[17:23:50] <Isarra> bawolff: What extension framework?
[17:24:07] <Isarra> Wait, is there an extension framework?
[17:24:13] <hexmode> heh
[17:24:52] <hexmode> I think there should be a HelloWorld extension that shows people best practices
[17:25:01] <hexmode> like GNU's hello program
[17:25:03] <mglaser>  :)
[17:25:10] <bawolff> hexmode: there is, its just not a very good example of best practises
[17:25:12] <greg-g> hexmode: personally, I love action items/goals with timelines/due dates in proposals. It's how I did them when applying for grant money from foundations.
[17:25:39] <bawolff> Q: "Work with vendors such as Microsoft to get funding to improve support for their products" - when you say things like that, do you mean secure funding to do that yourselves, or convince other people to do that sort of thing
[17:25:46] <greg-g> but, too much rigidity is restrictive, of course
[17:25:49] <bawolff> hexmode: Its in the examples extension repo
[17:26:11] <hexmode> greg-g: so, timelines we missed. other than "first year". We did get action items.
[17:26:13] <bawolff> I mean convince other people to do the coding
[17:26:32] <James_F> hexmode: I really like the focus on web-config, skins, anti-spam and help, but I also think easy-install-of-extensions-and-skins (like WordPress) would be worthwhile as shorter-term goals.
[17:26:41] <robla> we know from our experience at WMF that being too rigid in commitments in a grant application can be stifling and possibly counterproductive, so we understand why things are fuzzy there.
[17:27:11] <mglaser> bawolff: I see both options. In the first time, I don't think there will be any coding projects in the scope of this proposal. But yes, if someone seeks for help, I guess we can organize some skilled developer to help them, right?
[17:27:26] <greg-g> what robla said. I just used to work in that overly rigid world so I'm used to it :) But it has it's downfalls.
[17:27:30] <hexmode> James_F: sure, webconfig is good. probably do need to bump that up. And mglaser already has some good work on that
[17:27:37] * James_F nods.�
[17:27:57] <hexmode> but easy install needs focus
[17:28:16] <greg-g> [2 minute-ish warning]
[17:28:24] <bawolff> mglaser: Or as another example "Skinning sucks" - how do you plan to make it not suck
[17:28:44] * robla actually prefers focus on excellence in the release process itself as the main goal here, rather than shiny new features�
[17:28:49] <mglaser> But I want to get third parties interested in integration with MediaWiki. There have already been some example where companies were making (financial and resouce) efforts to get integrated.
[17:28:57] * bawolff would probably agree with robla�
[17:29:21] <greg-g> That's a good question to end on (robla's): what's your prioritization of those proposed things?
[17:29:23] <hexmode> my thoughts re funding. Haven't discussed this with mglaser, but I would like to see us be a clearinghouse for funding. We can start to collect funds and disemminate them for projects.
[17:29:42] <hexmode> so not that we would work with MS to get funding only for ourselves
[17:29:43] <mglaser> hexmode: sounds good to me
[17:29:49] <bawolff> That's an interesting idea
[17:29:52] <hexmode> but find people who are already doing work
[17:29:59] <hexmode> like dantman on skinning
[17:30:02] <Nikerabbit> will WMF in future have less power to say what goes or doesn't go into mw core?
[17:30:20] <bawolff> Would help to promote people doing work that is good for third parties, but not a WMF priority
[17:30:38] <hexmode> Nikerabbit: WMF will always be the primary user of MW so I think they get high priority
[17:30:39] <Nemo_bis> or rather, not to stop them as usually happens now
[17:31:08] <mglaser> bawolff: We should draw a clear line between form and function. If you want to customize a skin right now, you will most likely have to make changes that are not easy to upgrade.
[17:31:34] <mglaser> I think dantman has done some interesting work on this. This might be a way to follow
[17:31:35] <DanielFriesen> I may be well known for skinning but I do plenty of other big stuff too.
[17:31:43] <bawolff> Are there examples of WMF stopping things from going into core that they objected to on a "not-useful" basis, instead of a quality basis?
[17:31:57] <greg-g> [-1 minutes now, let's wrap this section up.]
[17:32:13] * hexmode is ready to move to discussion page�
[17:32:27] <bawolff> Most things I've seen WMF folks object to, was due to quality concerns, not some sort of "it isn't useful to us" concern
[17:32:35] <greg-g> yeah, this sounds like a good topic for bawolff and mglaser / hexmode for the talk: page
[17:32:39] <bawolff> ok
[17:32:51] <greg-g> Awesome. Thanks mark and mark :)
[17:32:51] <Nemo_bis> bawolff: also "oh no it would force us to run a maintenance script"
[17:33:02] <mglaser> bawolff: I agree. Let's talk on the talk page :=
[17:33:04] <mglaser>  :)
[17:33:14] <greg-g> Now, let's move on to the EIJL proposal. https://www.mediawiki.org/wiki/Release_Management_RFP/EIJL
[17:33:21] <legoktm> o/ hello
[17:33:25] <greg-g> wave hello again, E.I.J. and L :)
[17:33:59] <Emufarmers> Hi
[17:34:15] <bawolff> Hi EIJ and L
[17:34:46] <legoktm> so….any questions? :)
[17:35:02] <Elektra> hi!
[17:35:15] <bawolff> First off, to address what Isarra brought up earlier: What's wrong with our current extension framework, and what would you do differently?
[17:35:36] <greg-g> Yeah, extensions is a hot topic right now.
[17:35:40] <Isarra> I'm still surprised we even have an extension framework.
[17:35:43] <legoktm> well mainly is the way extensions are managed, and versioned
[17:36:05] <bawolff> Isarra: In so much as we have extensions, and they work without modifying core = "frameworK"
[17:36:24] <Elektra> too many breaking changes just "slip" to core and nobody notices 'em until the release is out and someone upgrades their site only to find out that stuff broke
[17:36:25] <legoktm> these days all new features (echo, VE, scribunto, etc) are being released as extensions, so any 3rd party re-user will have to interact with extensions no matter what
[17:37:17] * marktraceur is psyched to hear about new plans for extensions.�
[17:37:20] <bawolff> Isarra: Or to phrase it another way, what is in your definition of an "extension framework" that is not present in MediaWiki
[17:37:21] <greg-g> What would you all do differently (to pull out the last part of bawolff 's question)
[17:37:38] <legoktm> yeah like Elektra said, no one notices the breaking changes on non-WMF extensions, and the branch is already made, so it becomes a pain to try and get your 1 line patch backported, etc
[17:37:42] * bawolff wonders what plans these may be�
[17:38:58] <Isarra> bawolff: My dellusions tell me that extensions might be more stable and stuff if there were some sort of object they could extend and use that handle dependency listing (so if something in core breaks it, it'll be clear what, for instance, as well as if other extensions are required), as well as for version handling and other things.
[17:38:59] <legoktm> basically we want to set up tests and have automated and human reviews of all "supported" extensions before the releases are made
[17:39:23] <Isarra> Also testing. My delusions like the idea of more integrated and easier to set up testing.
[17:39:31] <Nikerabbit> what kind of human reviews?
[17:40:04] <greg-g> I assume you all would not be writing the test coverage for the extensions and would need extension author buy-in. Correct? Expand on this?
[17:40:05] <legoktm> Nikerabbit: having someone do basic checks to make sure the installation documentation is up to date and works, and the expected funtionality works
[17:40:23] <bawolff> Isarra: To be honest, I fail to see how extending some extension object would prevent core changes from breaking extensions
[17:40:41] <Isarra> Even someone just saying and commenting "This didn't explode when installed" could be useful to newcomers installing extensions.
[17:40:44] <bawolff> That only works if we know the change will break it, and the breaking changes that cause problems are the unknown change
[17:40:58] <Isarra> bawolff: Wouldn't prevent it, just make it clear WHAT broke it.
[17:41:14] <Nikerabbit> there are hundreds of extensions around which do complex things, do you have time to review them all or how will you prioritize?
[17:41:15] <bawolff> Isarra: But how?
[17:41:19] <Isarra> To prevent that sort of thing, it's core itself that needs proper testing and less random pointless changes without proper review.
[17:41:22] <Isarra> bawolff: Magic.
[17:41:31] <bawolff> Isarra: and Unicorns?
[17:41:33] <legoktm> greg-g: yes and no. we will definitely try and recruit extension authors to write tests, but we might write some of them ourselves (maybe as volunteers, not too sure on specifics yet)
[17:41:38] <Isarra> Actually, I don't know. That would be something to look into.
[17:42:01] <Isarra> bawolff: Maybe it wouldn't help at all, but establishing that would be useful in of itself.
[17:42:11] <bawolff> fair enough :)
[17:42:34] <bawolff> Moving on to testing. What are the pain points that you've noticed so far
[17:42:44] <greg-g> so, honest question: do we all just care about extensions, or are there other topics to bring up :)
[17:42:49] <legoktm> Nikerabbit: Yes, we do need to prioritize. We can use tools like http://wikiapiary.com to ensure that the more used extensions get full human reviews, and maybe the lesser ones get automated checks, or us sending a specific email to the extension maintainer
[17:43:02] <bawolff> Setting up parser tests in an extension are super easy imo (although not quite as useful as unit tests)
[17:43:17] <greg-g> [8 minutes until we switch to EIJL to asking questions, fyi]
[17:43:41] <Nemo_bis> wikiapiary is based on pavlo's list of 2009, we need an up to date list of wikis or it can't be considered representative
[17:43:48] <Nemo_bis> (marginal note but worth it)
[17:44:16] <hexmode> wikiapiary is open to submissions, even automated ones, fwiw
[17:44:33] <Nemo_bis> sorry I'm not going to hunt and add dozens thousands wikis manually
[17:44:37] <Isarra> bawolff: Testing doesn't bring up the major problems.
[17:44:40] <Nemo_bis> erm, is it brutal to ask about the price and justification for it
[17:44:41] <DanielFriesen> Sounds like someone needs to write a MediaWiki detecting web spider.
[17:44:45] <Nikerabbit> an annoyance is that the way mediawiki is written in a way doesn't encourage writing code that is easy to test, are you planning to do anything about that?
[17:44:50] <hexmode> Nemo_bis: sure, but there is already a list from wikistats ;)
[17:45:07] <legoktm> greg-g: well, realistically our goals are: release a new version of mediawiki, and try to fix extension versioning. Many of the other things (like skinning and spam fighting) we already do as volunteers and plan to do so
[17:45:10] <Isarra> So a wiki updates to 1.21 and OH HALF THE EXTENSIONS AREN'T COMPATIBLE ANYMORE! Gee, might have been nice to have some forewarning!
[17:45:14] <Isarra> ^ pain point.
[17:45:44] <Nemo_bis> hexmode: it's the same list
[17:45:45] <bawolff> Isarra: I mean in regards to "easier to set up testing" you mentioned above. What's hard about setting up testing?
[17:46:03] <Isarra> Oh. I have no idea how to set up testing.
[17:46:09] <Isarra> I don't even know what would need testing.
[17:46:18] <bawolff> So docs suck basically ;)
[17:46:25] <Isarra> For instance.
[17:46:25] <hexmode> Nemo_bis: hrm.. I saw some things missing. oh yeah, he only recently added support for non-api wikis
[17:46:33] <Nemo_bis> DanielFriesen: yes! we need one a lot, to know our users https://code.google.com/p/wikiteam/issues/detail?id=59
[17:46:47] <Isarra> And the docs are also all over the place. I mean, they're only scattered across three wikis now, but that's still bad.
[17:46:58] <robla> one question I have for the group: I'm assuming you all have day jobs and that this would be a secondary thing. are your day jobs compatible with the requirements for making the release process run well?
[17:47:04] <bawolff> Isarra: And that's assuming they exist :P
[17:47:14] <bawolff> at all
[17:47:14] <Isarra> Well, the ones that exist are. >.>
[17:47:21] <Isarra> I mean, already scattered.
[17:47:45] <legoktm> robla: Well some of us are still students. But yes, our schedules are compatible with the time needed to make it run well.
[17:48:02] <Nikerabbit> even when you are no longer students?
[17:48:21] <legoktm> That's one of the reasons we have a larger team, so we have a larger net, and can distribute the workload better
[17:49:28] <legoktm> Nikerabbit: I can't say with 100% certainty that yes, we will have time, but I can speak for all 4 of us and say that this is something we would enjoy doing, and would want to continue doing in the future
[17:49:47] <greg-g> How do you plan on managing communication between your team and everyone else? ie: would there be a single point of contact?
[17:50:52] <legoktm> greg-g: Yes, right now that would be me :). As mentioned in our proposal we plan on doing everything in the open, so we would keep a log of stuff on mw.o or somewhere else accessible.
[17:51:02] * greg-g nods�
[17:51:24] <greg-g> great. Any last questions for EIJL? or can we open it up to EIJL asking questions?
[17:51:33] <greg-g> [9 minutes remaining, officially]
[17:52:07] <greg-g> I'll assume EIJL can start asking question :)
[17:52:10] <greg-g> +s
[17:52:41] <Isarra> Does anyone know of some third-part public farm/family type projects there are besides shoutwiki and uncyclopedia?
[17:52:57] <bawolff> Wikia... :P
[17:53:11] <hexmode> WikiHow
[17:53:12] <hexmode>
[17:53:27] <Isarra> Wikia is pretty heavily involved in Wikimedia already... wikhow is on 1.12...
[17:53:40] <bawolff> I think there are a number of niche providers that are very small
[17:53:49] <hexmode> Isarra: Wikia is upgrading to 1.21 this fall, I think
[17:53:51] <bawolff> Isarra: I would disagree with that
[17:54:01] <bawolff> They are relative to other third parties
[17:54:21] <bawolff> But they have lots of patches to core code, that don't usually get contributed upstream
[17:54:30] <bawolff> (which is probably our fault)
[17:54:38] <DanielFriesen> There's also Yaron's Referata
[17:54:40] <hexmode> Isarra: I meant wikihow is upgrading
[17:54:53] <bawolff> Outside of visual editor, I'm not really aware of them being involved in mediawiki development
[17:54:56] <Isarra> Oh, really...
[17:55:03] <Isarra> Interesting.
[17:55:08] <Nikerabbit> I think they are nowdays keeping in touch with WMF, but not so much about MW I think
[17:55:52] <Isarra> Well, a lot of what Wikia does with Wikimedia, or wikimedia folks, is more extensions than core.
[17:55:55] <hexmode> getting their devs integrated into the dev community would be ideal
[17:56:06] <legoktm> Q: Is there anything you guys expect out of us that we haven't mentioned yet? We're always looking for feedback and suggestions for improvement :)
[17:56:27] <James_F> Isarra: Actually, a lot are hacks to core that they don't upstream and have to re-apply each time they push to a new version of MW (hence why it's such a pain for them).
[17:56:45] <James_F> Isarra: IME as the main "management" person working at WMF with Wikia. :-)
[17:57:24] <Isarra> There was also some stuff with flow and how to deal with that with messagewall and whatnot, among other things.
[17:57:32] <Isarra> But yeah, their core is quite patchy.
[17:57:38] <greg-g> legoktm: I like your specifics in the proposal, I just might wrap them with higher level end goals/big vision type things. (personally)
[17:58:33] <Nikerabbit> I haven't seen ashley say anything yet, is he here?
[17:58:35] <Isarra> Anyway, I'm wondering if perhaps the lack of other uses of mediawiki may have something to do with how the releases and updates are handled - it can be a complete pain to deal with that on the user end, and that's if one gets it set up at all.
[17:58:55] <legoktm> Nikerabbit: his bouncer was having issues, he's here as Elektra right now
[17:59:02] <Nikerabbit> oh
[17:59:03] <Isarra> Elektra: Tell us something angry!
[17:59:08] <Isarra> I mean...
[17:59:23] <legoktm> greg-g: Thanks. For the first few months we really just want to focus on the "releasing mediawiki", and then start expanding into bigger things once we have that down pat.
[17:59:32] <greg-g> awesome, thanks legoktm
[17:59:43] <greg-g> alright, so 1 minute left, officially
[18:00:00] <James_F> bawolff: BTW, would /really/ love Wikia's patched version of <gallery> to be upstreamed, even if hidden behind a preference so we don't have to enable it on WMF wikis immediately, maybe as part of your work on that? Hint hint. :-)
[18:00:00] <greg-g> Thanks everyone for coming and asking questions.
[18:00:03] <James_F> greg-g: Thank you!
[18:00:17] <mglaser> greg-g and all, thanks a lot!
[18:00:27] <DanielFriesen> What was the change to gallery?
[18:00:28] <bawolff> Q for greg-g / robla : Anything you can tell us about how these proposals will be evaluated beyond what was in the pdf?
[18:00:46] <greg-g> Also, I should say: please feel free to ping me (greg@wikimedia.org) with any private questions/concerns or hit up the proposals on wiki!
[18:01:07] <bawolff> DanielFriesen: Should we take this to #mediawiki, as its off topic here?
[18:01:41] <greg-g> bawolff: basically, I'm going to do some summarization work of this conversation (after I post the transcript to the list) and a few of us, notably robla, Erik, and myself, will sit down and review everything from everyone.
[18:01:59] <hexmode> robla, bawolff, greg-g: http://hexm.de/sg for discussion about release process excellence
[18:02:21] <greg-g> awesome, thanks hexmode
[18:02:28] <greg-g> ok, Thanks again everyone!
[18:02:37] <greg-g> enjoy the rest of your day and we're officially.... DONE!
[18:02:46] <Isarra> James_F: Has Wikia open-sourced their recent stuff?
[18:02:57] <legoktm> thanks everyone
[18:03:04] <greg-g> I should say: I'm really impressed with the proposals and excited to work on this with everyone.
[18:03:16] <James_F> Isarra: This is from 2006, but probably. Will bug someone about it later today.
[18:03:28] * greg-g waves goodbye�
[18:03:31] <Isarra> James_F: Excellent.
[18:03:33] <greg-g> marktraceur: #endmeeting

irclog2html output[edit]

Try the raw HTML from irclog2html (just the <body> tag content). Even without the irclog.css file (which styles the '*' IRC actions and such), it's not too bad. Wiki markup doesn't allow the hyperlink anchors for each timestamp, but a regexp could removee those or replace them with an anchor link:

* hexmode waves at mglaser <a href="#t16:51:10" class="time">16:51</a>
hexmode and the rest of you, too!<a href="#t16:51:17" class="time">16:51</a>

So let's remove it with the vim command %s!<a href="#.*class="time">\(.*\)</a>!\1!:

wikimedia-office/20130620.txt

* hexmode waves at mglaser 16:51
hexmode and the rest of you, too!16:51
mglaser hi there :)16:55
Emufarmers Hello16:55
legoktm hi16:55
Nikerabbit uga16:58
* marktraceur kicks James_F16:58
marktraceur Not allowed in here16:59
hexmode heh16:59
* James_F grins.16:59
hexmode and it begins17:00
greg-g Hello!17:00
greg-g Thanks for the topic change, marktraceur17:00
marktraceur greg-g: I can be your bot! :)17:00
greg-g So, let's just kick this off.17:00
greg-g marktraceur: #startmeeting17:01
mglaser :)17:01
greg-g Welcome, all to the office hours for the MediaWiki Release Management RFP17:01
bawolff greg-g: Perhaps send a note to #mediawiki and #wikimedia-dev to remind people who may have forgot17:01
greg-g we have hexmode and mglaser here from one of the proposals, is anyone here from the EIJL proposal?17:01
legoktm hey17:01
greg-g hello legoktm ! thanks for coming17:02
legoktm Emufarmers, Isarra, ashley and myself :)17:02
Emufarmers We have E, I, J, and L17:02
greg-g Great, a full house.17:02
greg-g So, I want to first open this up to others (ie: not me) to ask questions.17:02
greg-g How about we start with hexmode / mglaser's proposal: <a href="https://www.mediawiki.org/wiki/Release_Management_RFP/NicheWork_and_Hallo_Welt!" rel="nofollow">https://www.mediawiki.org/wiki/Release_Management_RFP/NicheWork_and_Hallo_Welt!</a>17:03
* hexmode is ready to answer ANYTHING17:03
greg-g There's been some discussion on the talk page for theirs, if people want to take a look: <a href="https://www.mediawiki.org/wiki/Talk:Release_Management_RFP/NicheWork_and_Hallo_Welt!" rel="nofollow">https://www.mediawiki.org/wiki/Talk:Release_Management_RFP/NicheWork_and_Hallo_Welt!</a>17:03
bawolff Q: Two people with Mark-esque names, are you worried there will be confusion?17:03
greg-g I second the question.17:04
* bawolff notes this is what you get when you say ask anything17:04
mglaser If nothing helps, we use numbers :)17:04
marktraceur bawolff: All marks are actually the same person in different costumes17:04
robla I don't think we could have a true Wikimedia initiative without name confusion17:04
hexmode bawolff: no.  I'm "hexmode" online mostly.  And our on-wiki names are distinct17:04
marktraceur It's an elaborate plan to get more candy on Halloween.17:04
greg-g marktraceur: quite elaborate.17:04
bawolff marktraceur: OMG its true, I've never seen them in the same (physical) room together17:05
mglaser and we both have beards ;)17:05
greg-g I don't want to make you two rehash your proposal here, but, we just got out of a discussion that deals with making life easier for extension owners/authors, what are you thoughts on that?17:05
hexmode you should have been at AMS -- we were both there on Friday.17:05
James_F Q: For those of us who do/used to run internal corporate MediaWiki instances (1.12, yay), you do think MW should move towards a more "enterprise"-like wiki model (e.g. granular security; files 'attached' to pages/namespaces), and if so, how do you see this happening/17:06
greg-g (continued...) I see it mentioned a few times in your prososal, and I like the general idea, just curious what specifcs you were thinking?17:06
* robla starts humming elevator music  :-)17:07
greg-g <audio src="jeopardy_theme.ogg">17:07
mglaser greg-g: first of all, work on extension versioning.17:07
mglaser It is not very clear which extension work with which MediaWiki Versions.17:08
mglaser and you can't expect tarball users to update on every MW release17:08
greg-g mglaser: completely. I've seen some use of Composer, were you thinking of going that route?17:09
hexmode James_F: So with people running 1.11 or 1.12, what they want is some stability and don't want to worry about upgrading every six months.17:09
hexmode James_F: first step is having an LTS that will be supported for a couple of years17:10
bawolff mglaser: How do you intend to work on that issue? I assume a lot of extension versioning would have to fall on the shoulders of extension maintainers. How do you plan to convince them to do that17:10
mglaser Yes, that's an option. I like relying on existing models instead of reinventing the wheel ourselves :)17:10
greg-g mglaser: good. :)17:10
hexmode James_F: and a clear path for support and upgrade17:10
mglaser bawolff, take wordpress for example. They have crowdsourced this: for a given combination of WP Version and Plugin Version, you can indicate whether this works for you.17:11
hexmode James_F: this ties into what mglaser is saying about extensions, too.  We haven't really discussed the LTS and extensions, but it would be good to get developers on-board with supporting the LTS in their extensions.17:11
Nikerabbit how often would there be LTS releases?17:12
mglaser when some people have done so, you get a good impression on what works17:12
Nikerabbit usually there is some overlap time where people can migrate to the next LTS version17:13
hexmode Nikerabbit: so <a href="https://www.mediawiki.org/wiki/Version_lifecycle" rel="nofollow">https://www.mediawiki.org/wiki/Version_lifecycle</a> shows every two years with an LTS getting 3 years of support.  I think that is right17:13
hexmode a year of overlap seems reasonable17:13
James_F hexmode: That page should probably be marked "speculative". :-)17:13
bawolff How do you feel LTS has been going so far?17:13
mglaser Also, to make it easier for extension developers, we need to find a way to handle breaking changes. Currently, these keep some extension maintainers away from updating their extensions. Not saying there should be no breaking changes, but they need to be communicated and documented very clearly, altogether with an upgrade path17:13
hexmode James_F: sure, but it is mostly my speculation ;)17:14
* James_F grins.17:14
Nikerabbit perhaps one important thing would be to announce the upcoming LTS releases before people break support for them in extensions (like I did)17:14
bawolff mglaser: I think any discussion on avoiding breaking changes, should have a concrete definition of what constitutes a breaking change17:15
hexmode bawolff: I haven't gotten backports made that I want to get made.  That has been mostly a time issue right now.  Hopefully with this proposal, I would have more time since I know my time would be compensated.17:15
greg-g Nikerabbit: are you thinking an overall roadmap/plan for the next LTS that is in place ~6 months in advance (or something?)?17:15
hexmode bawolff: but I'm happy with the security patches17:15
bawolff People do weird things in extensions. Sometimes a change that doesn't look breaking, can break somebodies weird hack of an extension17:15
Nikerabbit greg-g: just raising awareness, many people didn't/don't know that 1.19 has been nominated to be LTS release17:16
* greg-g nods17:16
mglaser bawolff, I agree. But there have been some major refactorings, eg ResourceLoader in the past. And I guess, Contenthandler might be the next candidate.17:16
James_F Nikerabbit: Also, the problem is that it sets expectations for MW extensions that their authors don't necessarily want / have the ability to support.17:16
hexmode Nikerabbit: how could we raise awareness?  I've done everything short of a blog post on the wmf blog.17:16
mglaser that is to say, ResourceLoader is really well documented.17:16
James_F hexmode: If you want a WMF blog post, just shout. :-)17:17
Nikerabbit hexmode: good question I don't have good suggestions17:17
Isarra Has there been anything on the release mailing list? Seems like one of the few things besides actual releases that would be relevant there.17:17
robla a lot of our hooks give access to large internal objects (e.g. User, Title) that it's harder to maintain backwards compatibility with, so we should be careful what we expose/encourage in our hooks17:17
hexmode Isarra: what do you mean?17:18
mglaser We might have a definition of "active extensions", where one requirement is to follow extensions-l or similar in order to be able to reach out to the developers17:18
greg-g (office keeping: I want to transition explicitly over to EIJL's proposal at :30, and I also want to give the proposers themselves time to ask us/the community questions, so I'll open it up for hexmode / mglaser to ask questions at ~ :20ish)17:18
Isarra There is a mailing list specifically for announcing releases so sysadmins know when to update - they would probably want to know if there is also now an LTS one.17:18
hexmode I mentioned the LTS in the 1.20 release announcement, but maybe that should be repeated.17:18
Isarra Yeah, I missed that.17:19
hexmode Isarra: good point17:19
Isarra Lumping stuff together, people tend to just see the first bits.17:19
hexmode todo: more visibility for the LTS17:19
mglaser One question is: would it be a good idea to *require* extension developers write some kind of tests?17:19
hexmode also announcements: I think Tim is the only person right now who can turn off emerg mod on the -announcments list17:20
bawolff mglaser: And what would be the consequences of if they didn't?17:20
Nikerabbit have it requirement to reach some sort of badge or quality level17:20
mglaser and then notify them if their extension is about to break in the next release17:20
greg-g hexmode: we can setup people with posting access to it as needed.17:20
Isarra You need a better extension framework before you can demand tests. Do you have plans for developing anything of that sort?17:20
hexmode badge/quality marking on-wiki for people with tests17:21
bawolff Some sort of test to ensure at the very least that the extension doesn't fatal out immediately upon load would be good17:21
mglaser bawolff: there could be a category "Extensions following our QA guidelines"17:21
greg-g so, before we switch to you all asking us/others questions: I'm curious on your thoguhts about KickStarter as that can sometimes be a huge timesink/failure if done incorrectly. What are you generally thoughts on that?17:21
bawolff I imagine part of the problem would be not all tests are created equal17:21
bawolff Its easy to make non-useful tests that pass no matter how broken the extension becomes17:21
hexmode greg-g: I suggested that, but I've seen very suprising successes with it17:22
bawolff Isarra: What do you feel is wrong with the extension framework currently?17:22
hexmode greg-g: if you know of a best-practices for kickstarter, I'm interested17:22
mglaser greg-g: I think, any Kickstarter campaign has to be prepared professionally. I guess, we might seek some external help there.17:22
mglaser From all I can see, this really makes a difference.17:22
bawolff Isarra: Or I guess we should get to that when the office hour switches over to your proposal17:23
greg-g Gotcha. Let's explore that more as needed, I'll ask some on the talk: page17:23
greg-g but, it is now :23, any questions from hexmode / mglaser of the community/us?17:23
hexmode what do you guys think we missed?17:23
Isarra bawolff: What extension framework?17:23
Isarra Wait, is there an extension framework?17:24
hexmode heh17:24
hexmode I think there should be a HelloWorld extension that shows people best practices17:24
hexmode like GNU's hello program17:25
mglaser :)17:25
bawolff hexmode: there is, its just not a very good example of best practises17:25
greg-g hexmode: personally, I love action items/goals with timelines/due dates in proposals. It's how I did them when applying for grant money from foundations.17:25
bawolff Q: "Work with vendors such as Microsoft to get funding to improve support for their products" - when you say things like that, do you mean secure funding to do that yourselves, or convince other people to do that sort of thing17:25
greg-g but, too much rigidity is restrictive, of course17:25
bawolff hexmode: Its in the examples extension repo17:25
hexmode greg-g: so, timelines we missed.  other than "first year". We did get action items.17:26
bawolff I mean convince other people to do the coding17:26
James_F hexmode: I really like the focus on web-config, skins, anti-spam and help, but I also think easy-install-of-extensions-and-skins (like WordPress) would be worthwhile as shorter-term goals.17:26
robla we know from our experience at WMF that being too rigid in commitments in a grant application can be stifling and possibly counterproductive, so we understand why things are fuzzy there.17:26
mglaser bawolff: I see both options. In the first time, I don't think there will be any coding projects in the scope of this proposal. But yes, if someone seeks for help, I guess we can organize some skilled developer to help them, right?17:27
greg-g what robla said. I just used to work in that overly rigid world so I'm used to it :) But it has it's downfalls.17:27
hexmode James_F: sure, webconfig is good.  probably do need to bump that up.  And mglaser already has some good work on that17:27
* James_F nods.17:27
hexmode but easy install needs focus17:27
greg-g [2 minute-ish warning]17:28
bawolff mglaser: Or as another example "Skinning sucks" - how do you plan to make it not suck17:28
* robla actually prefers focus on excellence in the release process itself as the main goal here, rather than shiny new features17:28
mglaser But I want to get third parties interested in integration with MediaWiki. There have already been some example where companies were making (financial and resouce) efforts to get integrated.17:28
* bawolff would probably agree with robla17:28
greg-g That's a good question to end on (robla's): what's your prioritization of those proposed things?17:29
hexmode my thoughts re funding.  Haven't discussed this with mglaser, but I would like to see us be a clearinghouse for funding.  We can start to collect funds and disemminate them for  projects.17:29
hexmode so not that we would work with MS to get funding only for ourselves17:29
mglaser hexmode: sounds good to me17:29
bawolff That's an interesting idea17:29
hexmode but find people who are already doing work17:29
hexmode like dantman on skinning17:29
Nikerabbit will WMF in future have less power to say what goes or doesn't go into mw core?17:30
bawolff Would help to promote people doing work that is good for third parties, but not a WMF priority17:30
hexmode Nikerabbit: WMF will always be the primary user of MW so I think they get high priority17:30
Nemo_bis or rather, not to stop them as usually happens now17:30
mglaser bawolff: We should draw a clear line between form and function. If you want to customize a skin right now, you will most likely have to make changes that are not easy to upgrade.17:31
mglaser I think dantman has done some interesting work on this. This might be a way to follow17:31
DanielFriesen I may be well known for skinning but I do plenty of other big stuff too.17:31
bawolff Are there examples of WMF stopping things from going into core that they objected to on a "not-useful" basis, instead of a quality basis?17:31
greg-g [-1 minutes now, let's wrap this section up.]17:31
* hexmode is ready to move to discussion page17:32
bawolff Most things I've seen WMF folks object to, was due to quality concerns, not some sort of "it isn't useful to us" concern17:32
greg-g yeah, this sounds like a good topic for bawolff and mglaser / hexmode for the talk: page17:32
bawolff ok17:32
greg-g Awesome. Thanks mark and mark :)17:32
Nemo_bis bawolff: also "oh no it would force us to run a maintenance script"17:32
mglaser bawolff: I agree. Let's talk on the talk page :=17:33
mglaser :)17:33
greg-g Now, let's move on to the EIJL proposal. <a href="https://www.mediawiki.org/wiki/Release_Management_RFP/EIJL" rel="nofollow">https://www.mediawiki.org/wiki/Release_Management_RFP/EIJL</a>17:33
legoktm o/ hello17:33
greg-g wave hello again, E.I.J. and L :)17:33
Emufarmers Hi17:33
bawolff Hi EIJ and L17:34
legoktm so….any questions? :)17:34
Elektra hi!17:35
bawolff First off, to address what Isarra brought up earlier: What's wrong with our current extension framework, and what would you do differently?17:35
greg-g Yeah, extensions is a hot topic right now.17:35
Isarra I'm still surprised we even have an extension framework.17:35
legoktm well mainly is the way extensions are managed, and versioned17:35
bawolff Isarra: In so much as we have extensions, and they work without modifying core = "frameworK"17:36
Elektra too many breaking changes just "slip" to core and nobody notices 'em until the release is out and someone upgrades their site only to find out that stuff broke17:36
legoktm these days all new features (echo, VE, scribunto, etc) are being released as extensions, so any 3rd party re-user will have to interact with extensions no matter what17:36
* marktraceur is psyched to hear about new plans for extensions.17:37
bawolff Isarra: Or to phrase it another way, what is in your definition of an "extension framework" that is not present in MediaWiki17:37
greg-g What would you all do differently (to pull out the last part of bawolff 's question)17:37
legoktm yeah like Elektra said, no one notices the breaking changes on non-WMF extensions, and the branch is already made, so it becomes a pain to try and get your 1 line patch backported, etc17:37
* bawolff wonders what plans these may be17:37
Isarra bawolff: My dellusions tell me that extensions might be more stable and stuff if there were some sort of object they could extend and use that handle dependency listing (so if something in core breaks it, it'll be clear what, for instance, as well as if other extensions are required), as well as for version handling and other things.17:38
legoktm basically we want to set up tests and have automated and human reviews of all "supported" extensions before the releases are made17:38
Isarra Also testing. My delusions like the idea of more integrated and easier to set up testing.17:39
Nikerabbit what kind of human reviews?17:39
greg-g I assume you all would not be writing the test coverage for the extensions and would need extension author buy-in. Correct? Expand on this?17:40
legoktm Nikerabbit: having someone do basic checks to make sure the installation documentation is up to date and works, and the expected funtionality works17:40
bawolff Isarra: To be honest, I fail to see how extending some extension object would prevent core changes from breaking extensions17:40
Isarra Even someone just saying and commenting "This didn't explode when installed" could be useful to newcomers installing extensions.17:40
bawolff That only works if we know the change will break it, and the breaking changes that cause problems are the unknown change17:40
Isarra bawolff: Wouldn't prevent it, just make it clear WHAT broke it.17:40
Nikerabbit there are hundreds of extensions around which do complex things, do you have time to review them all or how will you prioritize?17:41
bawolff Isarra: But how?17:41
Isarra To prevent that sort of thing, it's core itself that needs proper testing and less random pointless changes without proper review.17:41
Isarra bawolff: Magic.17:41
bawolff Isarra: and Unicorns?17:41
legoktm greg-g: yes and no. we will definitely try and recruit extension authors to write tests, but we might write some of them ourselves (maybe as volunteers, not too sure on specifics yet)17:41
Isarra Actually, I don't know. That would be something to look into.17:41
Isarra bawolff: Maybe it wouldn't help at all, but establishing that would be useful in of itself.17:42
bawolff fair enough :)17:42
bawolff Moving on to testing. What are the pain points that you've noticed so far17:42
greg-g so, honest question: do we all just care about extensions, or are there other topics to bring up :)17:42
legoktm Nikerabbit: Yes, we do need to prioritize. We can use tools like <a href="http://wikiapiary.com" rel="nofollow">http://wikiapiary.com</a> to ensure that the more used extensions get full human reviews, and maybe the lesser ones get automated checks, or us sending a specific email to the extension maintainer17:42
bawolff Setting up parser tests in an extension are super easy imo (although not quite as useful as unit tests)17:43
greg-g [8 minutes until we switch to EIJL to asking questions, fyi]17:43
Nemo_bis wikiapiary is based on pavlo's list of 2009, we need an up to date list of wikis or it can't be considered representative17:43
Nemo_bis (marginal note but worth it)17:43
hexmode wikiapiary is open to submissions, even automated ones, fwiw17:44
Nemo_bis sorry I'm not going to hunt and add dozens thousands wikis manually17:44
Isarra bawolff: Testing doesn't bring up the major problems.17:44
Nemo_bis erm, is it brutal to ask about the price and justification for it17:44
DanielFriesen Sounds like someone needs to write a MediaWiki detecting web spider.17:44
Nikerabbit an annoyance is that the way mediawiki is written in a way doesn't encourage writing code that is easy to test, are you planning to do anything about that?17:44
hexmode Nemo_bis: sure, but there is already a list from wikistats ;)17:44
legoktm greg-g: well, realistically our goals are: release a new version of mediawiki, and try to fix extension versioning. Many of the other things (like skinning and spam fighting) we already do as volunteers and plan to do so17:45
Isarra So a wiki updates to 1.21 and OH HALF THE EXTENSIONS AREN'T COMPATIBLE ANYMORE! Gee, might have been nice to have some forewarning!17:45
Isarra ^ pain point.17:45
Nemo_bis hexmode: it's the same list17:45
bawolff Isarra: I mean in regards to "easier to set up testing" you mentioned above. What's hard about setting up testing?17:45
Isarra Oh. I have no idea how to set up testing.17:46
Isarra I don't even know what would need testing.17:46
bawolff So docs suck basically ;)17:46
Isarra For instance.17:46
hexmode Nemo_bis: hrm.. I saw some things missing.  oh yeah, he only recently added support for non-api wikis17:46
Nemo_bis DanielFriesen: yes! we need one a lot, to know our users <a href="https://code.google.com/p/wikiteam/issues/detail?id=59" rel="nofollow">https://code.google.com/p/wikiteam/issues/detail?id=59</a>17:46
Isarra And the docs are also all over the place. I mean, they're only scattered across three wikis now, but that's still bad.17:46
robla one question I have for the group:  I'm assuming you all have day jobs and that this would be a secondary thing.  are your day jobs compatible with the requirements for making the release process run well?17:46
bawolff Isarra: And that's assuming they exist :P17:47
bawolff at all17:47
Isarra Well, the ones that exist are. >.>17:47
Isarra I mean, already scattered.17:47
legoktm robla: Well some of us are still students. But yes, our schedules are compatible with the time needed to make it run well.17:47
Nikerabbit even when you are no longer students?17:48
legoktm That's one of the reasons we have a larger team, so we have a larger net, and can distribute the workload better17:48
legoktm Nikerabbit: I can't say with 100% certainty that yes, we will have time, but I can speak for all 4 of us and say that this is something we would enjoy doing, and would want to continue doing in the future17:49
greg-g How do you plan on managing communication between your team and everyone else? ie: would there be a single point of contact?17:49
legoktm greg-g: Yes, right now that would be me :). As mentioned in our proposal we plan on doing everything in the open, so we would keep a log of stuff on mw.o or somewhere else accessible.17:50
* greg-g nods17:51
greg-g great. Any last questions for EIJL? or can we open it up to EIJL asking questions?17:51
greg-g [9 minutes remaining, officially]17:51
greg-g I'll assume EIJL can start asking question :)17:52
greg-g +s17:52
Isarra Does anyone know of some third-part public farm/family type projects there are besides shoutwiki and uncyclopedia?17:52
bawolff Wikia... :P17:52
hexmode WikiHow17:53
hexmode  17:53
Isarra Wikia is pretty heavily involved in Wikimedia already... wikhow is on 1.12...17:53
bawolff I think there are a number of niche providers that are very small17:53
hexmode Isarra: Wikia is upgrading to 1.21 this fall, I think17:53
bawolff Isarra: I would disagree with that17:53
bawolff They are relative to other third parties17:54
bawolff But they have lots of patches to core code, that don't usually get contributed upstream17:54
bawolff (which is probably our fault)17:54
DanielFriesen There's also Yaron's Referata17:54
hexmode Isarra: I meant wikihow is upgrading17:54
bawolff Outside of visual editor, I'm not really aware of them being involved in mediawiki development17:54
Isarra Oh, really...17:54
Isarra Interesting.17:55
Nikerabbit I think they are nowdays keeping in touch with WMF, but not so much about MW I think17:55
Isarra Well, a lot of what Wikia does with Wikimedia, or wikimedia folks, is more extensions than core.17:55
hexmode  getting their devs integrated into the dev community would be ideal17:55
legoktm Q: Is there anything you guys expect out of us that we haven't mentioned yet? We're always looking for feedback and suggestions for improvement :)17:56
James_F Isarra: Actually, a lot are hacks to core that they don't upstream and have to re-apply each time they push to a new version of MW (hence why it's such a pain for them).17:56
James_F Isarra: IME as the main "management" person working at WMF with Wikia. :-)17:56
Isarra There was also some stuff with flow and how to deal with that with messagewall and whatnot, among other things.17:57
Isarra But yeah, their core is quite patchy.17:57
greg-g legoktm: I like your specifics in the proposal, I just might wrap them with higher level end goals/big vision type things. (personally)17:57
Nikerabbit I haven't seen ashley say anything yet, is he here?17:58
Isarra Anyway, I'm wondering if perhaps the lack of other uses of mediawiki may have something to do with how the releases and updates are handled - it can be a complete pain to deal with that on the user end, and that's if one gets it set up at all.17:58
legoktm Nikerabbit: his bouncer was having issues, he's here as Elektra right now17:58
Nikerabbit oh17:59
Isarra Elektra: Tell us something angry!17:59
Isarra I mean...17:59
legoktm greg-g: Thanks. For the first few months we really just want to focus on the "releasing mediawiki", and then start expanding into bigger things once we have that down pat.17:59
greg-g awesome, thanks legoktm17:59
greg-g alright, so 1 minute left, officially17:59
James_F bawolff: BTW, would /really/ love Wikia's patched version of <gallery> to be upstreamed, even if hidden behind a preference so we don't have to enable it on WMF wikis immediately, maybe as part of your work on that? Hint hint. :-)18:00
greg-g Thanks everyone for coming and asking questions.18:00
James_F greg-g: Thank you!18:00
mglaser greg-g and all, thanks a lot!18:00
DanielFriesen What was the change to gallery?18:00
bawolff Q for greg-g / robla : Anything you can tell us about how these proposals will be evaluated beyond what was in the pdf?18:00
greg-g Also, I should say: please feel free to ping me (greg@wikimedia.org) with any private questions/concerns or hit up the proposals on wiki!18:00
bawolff DanielFriesen: Should we take this to #mediawiki, as its off topic here?18:01
greg-g bawolff: basically, I'm going to do some summarization work of this conversation (after I post the transcript to the list) and a few of us, notably robla, Erik, and myself, will sit down and review everything from everyone.18:01
hexmode robla, bawolff, greg-g: <a href="http://hexm.de/sg" rel="nofollow">http://hexm.de/sg</a> for discussion about release process excellence18:01
greg-g awesome, thanks hexmode18:02
greg-g ok, Thanks again everyone!18:02
greg-g enjoy the rest of your day and we're officially.... DONE!18:02
Isarra James_F: Has Wikia open-sourced their recent stuff?18:02
legoktm thanks everyone18:02
greg-g I should say: I'm really impressed with the proposals and excited to work on this with everyone.18:03
James_F Isarra: This is from 2006, but probably. Will bug someone about it later today.18:03
* greg-g waves goodbye18:03
Isarra James_F: Excellent.18:03
greg-g marktraceur: #endmeeting18:03

Generated by irclog2html.py 2.12.1 by <a href="mailto:marius@pov.lt">Marius Gedminas</a> - find it at <a href="http://mg.pov.lt/irclog2html/">mg.pov.lt</a>!