On Fri, Jan 22, 2016 at 5:30 PM, Rob Lanphier <robla(a)wikimedia.org> wrote: Perhaps you could elaborate on the "WMF TechOps" aspect a bit, either here in email or on the Phab ticket. It seems that some of the tasks currently tagged as "RfCs" are actually not ArchCom RfCs (they are WikiData-related?). From your description above, it seems there may also be some not-quite-ArchCom RfCs related to what software gets deployed on our cluster. Perhaps we should try to come up with more fine-grained labels for RfCs, rather than labelling them all "ArchCom RfCs"? I think there was some discussion at the dev summit about trying to associate proposals with the dev summit "working groups", as a way of communicating a broad agenda for each ArchCom meeting. Finer-grained RfC labeling might be part and parcel of this. --scott (who isn't opposed to the proposed relabeling in any way, just thinking perhaps this is an opportunity for better classification)

On Fri, Jan 22, 2016 at 02:30:22PM -0800, Rob Lanphier wrote: This is true, although the word "blocked" is perhaps a bit strong. We generally prefer large architectural changes to be discussed with a wider group across the movement, than just us and the person or team that proposed them. An architecture that grows organically without much coordination or cohesion isn't going to be sane, but a process where TechOps are the gatekeeper for every single architectural change is not a healthy one either. Hence our... recommendation to move those discussions into the RfC forum, for the lack of a better venue. That said, there have been important deployments that have bypassed the RfC process entirely (including proposals that resulted into staffed WMF teams) and others that did go via the RfC process, but the resulting feedback wasn't incorporated into the final design (for various reasons). It's also worth noting that the opposite has happened as well: TechOps has blocked the production deployment of features that the MediaWiki ArchComm has approved. The fact that an optional feature is considered good enough for the MediaWiki architecture does not mean that it's appropriate for Wikimedia's complex and demanding production environment -- or for being worked on by the Wikimedia Foundation, for that matter. This is especially true given that ArchComm really has absolutely no say in resourcing and a given feature may not have secured funding (people, hardware etc.) Faidon

On 28 January 2016 at 18:53, Rob Lanphier <robla(a)wikimedia.org> wrote: He wouldn't be the only one who thinks this. I've seen other people with similar concerns about whether ArbComm is really in control or whether WMF management is, because it's WMF management that actually gets to decide what the paid Wikimedia developers (probably the majority of active developers at this point) work on. I'm inclined to agree with them.

<quote name="Alex Monk" date="2016-01-28" time="19:07:09 +0000"> This is similar to the concern/line of reasoning that lead to all of the questions about whether or not "WMF senior leadership" will be in active attendance at the Dev Summit. -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

<quote name="Rob Lanphier" date="2016-01-28" time="11:52:11 -0800"> I think the charitable interpretation is that it was/is unclear to some (I'm mostly going off of my interpretation of some of the questions asked during the planning phase of the DevSummit here (aka: hearsay)) if the DevSummit was going to be a "place of decisions" or something else (education, etc), and if it was to be a place of decisions then without explicit buy-in from WMF management those decisions could be less-than-timely implemented (if those who could do the implementation were a contested "resource" with some other high priority request that wasn't at the DevSummit). Apologies for my long sentence with too many parentheticals. Except for when what I outlined above happens, aka something that has general consensus within the "community" and even ArchCom doesn't get any legs because those who could/should do it are tasked with other things. In other words: it's not unreasonable to assume those people won't spend their personal time doing that work. However, this might be rat-holing on this one aspect around "resourcing", so I'm willing to both be told I'm wrong and drop it. Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

<quote name="Wes Moran" date="2016-01-28" time="18:34:30 -0500"> Thanks Wes. I just want to add (I swear I'm done now) that I think that is the right approach, generally: Constant assessment by/from WMF "management" on what to prioritize/staff based on input from all sources (comm wishlist, devsummit, archcom, etc). In reality, it's the only thing that makes sense ("Listen to all input, discuss options, decide."). Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

On Mon, Jan 25, 2016 at 9:59 AM, Matthew Flaschen &lt;mflaschen(a)wikimedia.org&gt; wrote: Logically, I think your long-term vision makes sense. Managing the software we deploy to the WIkimedia cluster is a lot of work, and it deserves focus. In the short-term, I believe a non-Wikimedia focused subgroup of ArchCom may make sense. The declining MediaWiki use outside of Wikimedia has been a longstanding problem for us, but not the biggest problem. ArchCom's focus is (and should continue to be) the needs of Wikimedia. The reason why I'm delineating it as a subgroup is not a power grab, but an essential step toward building the trust required for long term viability of a MediaWiki(?) Foundation to be viable. The fact that the people working on the "MediaWiki Foundation" are still(!) using the name "MediaWiki" represents a failure of imagination among all of us. For example, if MW Stake wants to be a viable upstream, there has to be a stake/steak pun buried in there somewhere that could represent a great name for a viable fork of MediaWiki. Yes, I used the word "fork". I believe Wikimedia Foundation would love it if MediaWiki forked, and we were "forced" to switch to the fork. There are other projects (e.g. gcc, KHTML/WebKit, Inkscape) that were helped by a fork. WMF wouldn't be offended at all by an attempt to create a viable fork, as we know that there is a limit to how much we work we should try to fund off of our current donation model. If we should be pressuring anyone to make non-Wikimedia use of MediaWiki viable, it shouldn't be WMF, someone from Wikia should step up. :-P As it stands, Wikimedia Foundation is the only trusted upstream for the MediaWiki codebase. I believe WMF should jealously guard the "MediaWiki" trademark, if for no other reason than to force someone to come up with a different name. "MediaWiki" and "Wikimedia" are too similar, and there are not good reasons for us to license that trademark to anyone else. WMF doesn't have a patent on the alphabet; come up with your own damn name ;-) Naming isn't the only issue for a viable fork, though. There are other things that a viable fork would need for WMF to trust it: - An upstream repository. This could be anywhere (even Github!). We would need to be able to trust that upstream would collaborate with us to solve our dealbreakers. - Trusted architects with clear vision and leadership - A governance structure that allows WMF to operate as a worthy peer We have healthy relationships with other upstreams (e.g. Phabricator, Debian, Composer), and though we don't always agree with the choices of our upstream, we strive to collaborate with respect, and we figure out what to do if upstream makes a choice that creates a problem for us. So: forks welcome! Any takers? Rob

On Mon, Jan 25, 2016 at 3:16 PM, Rob Lanphier &lt;robla(a)wikimedia.org&gt; wrote: I would love to fork MediaWiki. Only problem: I'm employed by the WMF. That would make it a "captive fork" and not actually useful from the "MediaWiki Foundation" standpoint. However, I've *also* got far too many projects on my plate already, so instead I'll briefly outline what my "dream fork" would look like, in the hopes that someone else will take this ball and run with it: Goal #1: 100% compatibility with existing MediaWiki content. This doesn't (necessarily) mean that the databases need to be the same, or even that it needs to use wikitext, just that it has good conversion tools "on day 1". Anti-goal #1: 100% compatibility with MediaWiki *features*. That is, the MW core codebase has accumulated a lot of cruft over time. It shouldn't be a goal to support *every* possible database backend, special page, or extension supported by MediaWiki, in fact *not* doing so is exactly why the fork is needed (the WMF has its hands tied by trying to make every possible user base happy). For existing MediaWiki users to migrate this fork, it needs dead-simple conversion from existing MediaWiki installations (that's goal #1) but it also needs some compelling new features. This is actually the easy part, I think -- WMF is quite tightly constrained by the existing MediaWiki UX, so there are lots of ideas floating around out there on how to improve things on the frontend. There's also quite a lot of enthusiasm for (say) "github-style" content storage on the backend. Either one of those things (or a dozen others) could provide compelling reasons for users to switch. "Just a fresh look" could be enough. The WMF is tightly constrained in ways that a potential fork would not be; not least by our focus on "Encyclopedic" content. Prior to employment by the WMF I worked with MediaWiki for internal documentation within a number of different technology organizations (heck, WMF itself uses MW this way on wikitech.wikimedia.org and mediawiki.org) and in most of those contexts a much more code-focused/version control centric/"markdown"-looking (ie, easy ways to write <code> blocks) UX would be compelling. This is a great opportunity to make some changes that the WMF can't/won't make in order to fit a non-encyclopedic need. (Not to mention non-text media, etc. There are products to create libraries on in-house 2d/3d artistic content, used for games, films, and graphic design; the present MW is almost entirely unsuited to this.) Now, for the WMF to eventually migrate to this fork, it would need to *eventually* be capable of doing all the things the WMF uses MW for in the Wikipedia projects and others. But I'd urge any prospective forkers to think *long term* about this. Trying to do all WMF things on day one is probably not the best way to make your fork compelling for some group of users, and you'll need the support of that group of users in order to grow and maintain your fork. Let the WMF worry about migration and compatibility when it comes to it. Concentrate first on building something great. --scott ps. Here's a grab bag of further fork ideas. None of these are *necessary*, of course, and some of them in fact may be *unwise*. But maybe these will stir the soul and trigger the coding fingers of someone out there: * Parsoid provides an excellent substrate for translating existing wikitext into <something better>, whatever you choose that to be. Parsoid's motto: "we deal with wikitext, so you don't have to". We also have good ContentHandler abstractions in core so that you could treat wikitext as a "legacy format" in your fork, and use "something better" by default. (Markdown is popular with the kids, and there are lots of popular templating systems these days.) * Forking MediaWiki means that you can use all the latest PHP features, right off the bat. Or else ditch PHP entirely! It's up to you. Maybe use ES2015 JavaScript. I do suggest sticking to one of the "major" languages if you wish your fork to have legs... although I'd love to see what an OCaml-native MediaWiki would look like. (Or you could code in a hybrid system, like https://phabricator.wikimedia.org/T114457 , and try to have the best of multiple worlds.) * You can change the implementation language but keep the database schema. Or do the opposite. Lots of ways to avoid reinventing the entire wheel. * MediaWiki is multilingual in theory, but in practice i18n features haven't gotten a lot of love in the past decade. What would a MediaWiki built around modern machine translation (and spell/grammar correction) look like? We tend to build these features around "big data" these days, and WP is quite a "big data" source. * I'd love to see more real-time and social features integrated from the start. But you should probably keep in mind what it takes to create a safe community as well. Too many "clean sheet" redesigns foster harassment inadvertently by omission. * When in doubt, steal! There are undoubtedly lots of other bits of code you can steal; there's no reason MediaWiki needs to do quite as many bespoke things as it does. Maybe if you weld together a slack clone, gitlab, and Parsoid you could get all messaging, backend storage, and wikitext rendering "for free". (See https://phabricator.wikimedia.org/T105175 for more "easy front end" ideas.) Mashing big pieces together might be the best way to build something compelling quickly (and keep the core code you have to maintain small). (http://cscott.net)

On Mon, Jan 25, 2016 at 4:27 PM, Brad Jorsch (Anomie) &lt;bjorsch(a)wikimedia.org > On Mon, Jan 25, 2016 at 4:06 PM, C. Scott Ananian &lt;cananian(a)wikimedia.org&gt; > > > On Mon, Jan 25, 2016 at 3:16 PM, Rob Lanphier &lt;robla(a)wikimedia.org&gt; > > > > > So: forks welcome! Any takers? > > You seem to be assuming that "fork" === "complete rewrite". That's not > necessarily the case, nor is it necessarily even desirable. > I thought I made it clear that a fork could be any combination of things, up to and including (but not necessarily!) a complete rewrite. Perhaps I didn't actually make that clear enough, so I'll state it again: * You should feel free to use (or not use) as much (or as little) of the existing mediawiki code as you like. The important thing (IMO) is that the fork should be easy to migrate to, and better serve some use case which the existing mediawiki neglects. --scott

On 01/25/2016 05:58 PM, Alex Monk wrote: I don't know if anyone has the resources for a fork, and as stated, I think the non-fork route should be tried first. *However*, I have heard (in the source of these discussions) there are some resources that could be donated to MW development if there were an organization focused on the product itself and able to accept those donations (for WMF, that would not be accepted, as a restricted donation). Matt Flaschen

Hi, On 01/27/2016 12:46 PM, Matthew Flaschen wrote: These aren't exactly stats, but I think the Google Trends graph of "MediaWiki" vs. "Confluence" shows a relevant picture: <https://www.google.com/trends/explore#q=mediawiki%2C%20confluence&cmpt=q&tz=Etc%2FGMT-11> -- Legoktm