User:SPage (WMF)/ReleaseManagementRFP IRC log
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
editTry 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
editTry 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 | Hello | 16:55 |
| legoktm | hi | 16:55 |
| Nikerabbit | uga | 16:58 |
| * marktraceur kicks James_F | 16:58 | |
| marktraceur | Not allowed in here | 16:59 |
| hexmode | heh | 16:59 |
| * James_F grins. | 16:59 | |
| hexmode | and it begins | 17:00 |
| greg-g | Hello! | 17:00 |
| greg-g | Thanks for the topic change, marktraceur | 17: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: #startmeeting | 17:01 |
| mglaser | :) | 17:01 |
| greg-g | Welcome, all to the office hours for the MediaWiki Release Management RFP | 17:01 |
| bawolff | greg-g: Perhaps send a note to #mediawiki and #wikimedia-dev to remind people who may have forgot | 17:01 |
| greg-g | we have hexmode and mglaser here from one of the proposals, is anyone here from the EIJL proposal? | 17:01 |
| legoktm | hey | 17:01 |
| greg-g | hello legoktm ! thanks for coming | 17:02 |
| legoktm | Emufarmers, Isarra, ashley and myself :) | 17:02 |
| Emufarmers | We have E, I, J, and L | 17: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 ANYTHING | 17: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 anything | 17:04 | |
| mglaser | If nothing helps, we use numbers :) | 17:04 |
| marktraceur | bawolff: All marks are actually the same person in different costumes | 17:04 |
| robla | I don't think we could have a true Wikimedia initiative without name confusion | 17:04 |
| hexmode | bawolff: no. I'm "hexmode" online mostly. And our on-wiki names are distinct | 17: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 together | 17: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 release | 17: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 years | 17: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 that | 17: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 upgrade | 17: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 works | 17:12 |
| Nikerabbit | usually there is some overlap time where people can migrate to the next LTS version | 17: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 right | 17:13 |
| hexmode | a year of overlap seems reasonable | 17: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 path | 17: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 change | 17: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 patches | 17:15 |
| bawolff | People do weird things in extensions. Sometimes a change that doesn't look breaking, can break somebodies weird hack of an extension | 17:15 |
| 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 |
| * greg-g nods | 17: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 suggestions | 17: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 hooks | 17: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 developers | 17: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 point | 17:19 |
| Isarra | Lumping stuff together, people tend to just see the first bits. | 17:19 |
| hexmode | todo: more visibility for the LTS | 17: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 list | 17: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 level | 17:20 |
| mglaser | and then notify them if their extension is about to break in the next release | 17: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 tests | 17:21 |
| 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 |
| 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 equal | 17:21 |
| bawolff | Its easy to make non-useful tests that pass no matter how broken the extension becomes | 17:21 |
| hexmode | greg-g: I suggested that, but I've seen very suprising successes with it | 17: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 interested | 17: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 proposal | 17:23 |
| greg-g | Gotcha. Let's explore that more as needed, I'll ask some on the talk: page | 17: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 | heh | 17:24 |
| hexmode | I think there should be a HelloWorld extension that shows people best practices | 17:24 |
| hexmode | like GNU's hello program | 17:25 |
| mglaser | :) | 17:25 |
| bawolff | hexmode: there is, its just not a very good example of best practises | 17: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 thing | 17:25 |
| greg-g | but, too much rigidity is restrictive, of course | 17:25 |
| bawolff | hexmode: Its in the examples extension repo | 17: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 coding | 17: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 that | 17:27 |
| * James_F nods. | 17:27 | |
| hexmode | but easy install needs focus | 17: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 suck | 17:28 |
| * robla actually prefers focus on excellence in the release process itself as the main goal here, rather than shiny new features | 17: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 robla | 17: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 ourselves | 17:29 |
| mglaser | hexmode: sounds good to me | 17:29 |
| bawolff | That's an interesting idea | 17:29 |
| hexmode | but find people who are already doing work | 17:29 |
| hexmode | like dantman on skinning | 17: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 priority | 17:30 |
| hexmode | Nikerabbit: WMF will always be the primary user of MW so I think they get high priority | 17:30 |
| Nemo_bis | or rather, not to stop them as usually happens now | 17: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 follow | 17: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 page | 17: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" concern | 17:32 |
| greg-g | yeah, this sounds like a good topic for bawolff and mglaser / hexmode for the talk: page | 17:32 |
| bawolff | ok | 17: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/ hello | 17:33 |
| greg-g | wave hello again, E.I.J. and L :) | 17:33 |
| Emufarmers | Hi | 17:33 |
| bawolff | Hi EIJ and L | 17: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 versioned | 17: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 broke | 17: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 what | 17: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 MediaWiki | 17: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, etc | 17:37 |
| * bawolff wonders what plans these may be | 17: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 made | 17: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 works | 17:40 |
| bawolff | Isarra: To be honest, I fail to see how extending some extension object would prevent core changes from breaking extensions | 17: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 change | 17: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 far | 17: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 maintainer | 17: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 representative | 17:43 |
| Nemo_bis | (marginal note but worth it) | 17:43 |
| hexmode | wikiapiary is open to submissions, even automated ones, fwiw | 17:44 |
| Nemo_bis | sorry I'm not going to hunt and add dozens thousands wikis manually | 17: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 it | 17: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 so | 17: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 list | 17: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 wikis | 17: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 :P | 17:47 |
| bawolff | at all | 17: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 better | 17: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 future | 17: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 nods | 17: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 | +s | 17:52 |
| Isarra | Does anyone know of some third-part public farm/family type projects there are besides shoutwiki and uncyclopedia? | 17:52 |
| bawolff | Wikia... :P | 17:52 |
| hexmode | WikiHow | 17: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 small | 17:53 |
| hexmode | Isarra: Wikia is upgrading to 1.21 this fall, I think | 17:53 |
| bawolff | Isarra: I would disagree with that | 17:53 |
| bawolff | They are relative to other third parties | 17:54 |
| bawolff | But they have lots of patches to core code, that don't usually get contributed upstream | 17:54 |
| bawolff | (which is probably our fault) | 17:54 |
| DanielFriesen | There's also Yaron's Referata | 17:54 |
| hexmode | Isarra: I meant wikihow is upgrading | 17:54 |
| bawolff | Outside of visual editor, I'm not really aware of them being involved in mediawiki development | 17: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 think | 17: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 ideal | 17: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 now | 17:58 |
| Nikerabbit | oh | 17: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 legoktm | 17:59 |
| greg-g | alright, so 1 minute left, officially | 17: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 excellence | 18:01 |
| greg-g | awesome, thanks hexmode | 18: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 everyone | 18: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 goodbye | 18:03 | |
| Isarra | James_F: Excellent. | 18:03 |
| greg-g | marktraceur: #endmeeting | 18: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>!