Hi everyone,
Those with a keen eye will notice that I filed T124255 https://phabricator.wikimedia.org/T124255, which calls for renaming #MediaWIki-RfCs in Phab to "#ArchCom-RfC". This would be a boring Phab administrivia email if it was simply that.
The reason I want the rename: ArchCom is the mechanism we hope to ensure we build and deploy increasingly excellent software on the Wikimedia production cluster in a consensus-oriented manner. MediaWiki is at the center of this, but ArchCom's responsibility doesn't end with MediaWiki.
T124255 https://phabricator.wikimedia.org/T124255 is an odd place to have a more sweeping conversation about the scope of ArchCom, but it'll do for now. Feel free to comment there or on this mailing list.
Thanks Rob
To clarify - are you saying this is the actual current scope of ArchCom, or are you advocating for a change in scope?
On 22 January 2016 at 22:03, Rob Lanphier robla@wikimedia.org wrote:
ArchCom is the mechanism we hope to ensure we build and deploy increasingly excellent software on the Wikimedia production cluster in a consensus-oriented manner. MediaWiki is at the center of this, but ArchCom's responsibility doesn't end with MediaWiki.
On Fri, Jan 22, 2016 at 2:08 PM, Alex Monk krenair@gmail.com wrote:
To clarify - are you saying this ([deploying increasingly excellent software on the Wikimedia production cluster in a consensus-oriented manner]) is the actual current scope of ArchCom, or are you advocating for a change in scope?
It's my attempt to clarify the scope, but you could argue it's a change.
Ultimately, WMF TechOps has correctly blocked a lot of software making it to the Wikimedia cluster that hasn't been through the RFC process, even though they themselves weren't entirely clear about the scope. Wikimedia Foundation leadership has an (unfortunately) long history of being unclear about the scope. I share the blame for this. This is my attempt to clarify.
Rob
On Fri, Jan 22, 2016 at 5:30 PM, Rob Lanphier robla@wikimedia.org wrote:
On Fri, Jan 22, 2016 at 2:08 PM, Alex Monk krenair@gmail.com wrote:
To clarify - are you saying this ([deploying increasingly excellent software on the Wikimedia production cluster in a consensus-oriented manner]) is the actual current scope of ArchCom, or are you advocating
for
a change in scope?
It's my attempt to clarify the scope, but you could argue it's a change.
Ultimately, WMF TechOps has correctly blocked a lot of software making it to the Wikimedia cluster that hasn't been through the RFC process, even though they themselves weren't entirely clear about the scope. Wikimedia Foundation leadership has an (unfortunately) long history of being unclear about the scope. I share the blame for this. This is my attempt to clarify.
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 2:58 PM, C. Scott Ananian cananian@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.
My "WMF TechOps" term was a slightly inaccurate way of describing the "Ops" column in this table: https://meta.wikimedia.org/wiki/System_administrators
A relevant part to quote: "The Wikimedia Foundation https://meta.wikimedia.org/wiki/Wikimedia_Foundation legally controls the servers; ultimately the Wikimedia Foundation Board of Trustees https://wikimediafoundation.org/wiki/Board_of_Trustees is responsible for determining who has *sysadmin* access, and how that responsibility is exercised. However, this power is delegated to various Wikimedia Foundation managers https://wikimediafoundation.org/wiki/Staff_and_contractors. On a day-to-day basis, various system administrators with root or shell access manage the server clusters."
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.
I would like one board to monitor for what is actually about to be approved. Per T123606 https://phabricator.wikimedia.org/T123606, I would *love* for working groups to assume a lot of the earlier drafting/workflow aspects of things, and Phab labels for that would be great. I think we need to agree on the working groups we want (see T124504 https://phabricator.wikimedia.org/T124504) before we start on the administrative detail of what tags we want.
Rob
On Fri, Jan 22, 2016 at 02:30:22PM -0800, Rob Lanphier wrote:
On Fri, Jan 22, 2016 at 2:08 PM, Alex Monk krenair@gmail.com wrote:
To clarify - are you saying this ([deploying increasingly excellent software on the Wikimedia production cluster in a consensus-oriented manner]) is the actual current scope of ArchCom, or are you advocating for a change in scope?
It's my attempt to clarify the scope, but you could argue it's a change.
Ultimately, WMF TechOps has correctly blocked a lot of software making it to the Wikimedia cluster that hasn't been through the RFC process, even though they themselves weren't entirely clear about the scope. Wikimedia Foundation leadership has an (unfortunately) long history of being unclear about the scope. I share the blame for this. This is my attempt to clarify.
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
Thanks for articulating this very clearly Faidon! More inline...
On Thu, Jan 28, 2016 at 3:11 AM, Faidon Liambotis faidon@wikimedia.org wrote:
On Fri, Jan 22, 2016 at 02:30:22PM -0800, Rob Lanphier wrote:
Ultimately, WMF TechOps has correctly blocked a lot of software making it to the Wikimedia cluster that hasn't been through the RFC process, even though they themselves weren't entirely clear about the scope. Wikimedia Foundation leadership has an (unfortunately) long history of being
unclear
about the scope. I share the blame for this. This is my attempt to clarify.
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. [ArchCom seems to be more diverse than Ops, and
probably better than leaving it up to Ops to keep organic growth under
control] 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).
I definitely appreciate it when Ops has been a firm stakeholder in this process. Mark unofficially dropped out of ArchCom back in August, which I only recently acknowledged on the ArchCom page https://www.mediawiki.org/wiki/Architecture_committee (sorry!) The remaining ArchCom members have been very good at ensuring that Ops' voice is reflected in the decisions (e.g. the schema change update to the development policy https://www.mediawiki.org/wiki/Development_policy)
It seems reasonable for y'all to object to deployments of code for which consensus isn't clear. We shouldn't expect you to be the police, and you need to be careful about maintaining the trust and goodwill of the broader community (and not seen as an obstacle to progress), but when you see <something> that doesn't look right, a polite note to wikitech-l saying "I'm confused about <something>" would be greatly appreciated.
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 a failure of process we should address. ArchCom shouldn't approve things that don't make sense for our environment.
That said, we want Wikimedia software to improve quickly. We should aspire to incorporate the best elements of the "bold, revert, discuss https://meta.wikimedia.org/wiki/Bold,_revert,_discuss" consensus-building process that serves many of our projects well. We should endeavor to take acceptable risks for things that are easily reversible, and only challenge those risks where the consequences of failure aren't clearly understood and/or disproportionately fall on the wrong people.
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.)
Awww....you're mail was so great, and then you ended with this! Are you saying that the only real power in this world belongs to people with control of the money?
Rob
On 28 January 2016 at 18:53, Rob Lanphier robla@wikimedia.org wrote:
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.)
Awww....you're mail was so great, and then you ended with this! Are you saying that the only real power in this world belongs to people with control of the money?
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.
(I did, of course, mean Ar*ch*Comm there, yes. Thanks to those of you who pointed it out.)
On 28 January 2016 at 19:07, Alex Monk krenair@gmail.com wrote:
On 28 January 2016 at 18:53, Rob Lanphier robla@wikimedia.org wrote:
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.)
Awww....you're mail was so great, and then you ended with this! Are you saying that the only real power in this world belongs to people with control of the money?
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">
On 28 January 2016 at 18:53, Rob Lanphier robla@wikimedia.org wrote:
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.)
Awww....you're mail was so great, and then you ended with this! Are you saying that the only real power in this world belongs to people with control of the money?
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.
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.
On Thu, Jan 28, 2016 at 11:21 AM, Greg Grossmeier greg@wikimedia.org wrote:
<quote name="Alex Monk" date="2016-01-28" time="19:07:09 +0000"> > On 28 January 2016 at 18:53, Rob Lanphier <robla@wikimedia.org> wrote: > > > 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.) > > > > > > > Awww....you're mail was so great, and then you ended with this! Are you > > saying that the only real power in this world belongs to people with > > control of the money? > > > 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.
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.
Also, Wes Moran gave the keynote, and didn't say anything to contradict what I said in my email. Is there something I missed there?
Generally speaking, the position WMF executive management has taken in the conversations that I've had is that WMF needs to do a better job listening to the community. Saying that ArchCom has "no say" basically is taking a needlessly fatalistic stance of a mindless wage slave. I know y'all well enough to know that everyone on this thread is intensely mission-driven, and "mindless" is about as far from a truthful description anyone could give.
ArchCom strives to define what we should do, based on listening to the community and using our collective expertise to craft a vision based on what we learn. What "WMF senior leadership" (pls define) does with that information is probably not in scope for this mailing list.
Rob
<quote name="Rob Lanphier" date="2016-01-28" time="11:52:11 -0800">
Generally speaking, the position WMF executive management has taken in the conversations that I've had is that WMF needs to do a better job listening to the community. Saying that ArchCom has "no say" basically is taking a needlessly fatalistic stance of a mindless wage slave. I know y'all well enough to know that everyone on this thread is intensely mission-driven, and "mindless" is about as far from a truthful description anyone could give.
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.
ArchCom strives to define what we should do, based on listening to the community and using our collective expertise to craft a vision based on what we learn. What "WMF senior leadership" (pls define) does with that information is probably not in scope for this mailing list.
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
Yeah I was there and enjoyed it, thanks again Rob and Quim. There were many good discussions that help us align and structure the thinking. It takes a lot of thought, data and discussion to know what to build, before you make the commitment to build it. At the dev summit many of the teams that influence budget allocation (Ideally a participatory process, not management alone) participated and are active in proposals. The review and cross team discussions on efforts like the Community Wishlist, Dev Summit Proposals and ArchCom are considered by teams on a regular basis and then put into the planning of where resources align.
Wes
On Thu, Jan 28, 2016 at 2:52 PM, Rob Lanphier robla@wikimedia.org wrote:
On Thu, Jan 28, 2016 at 11:21 AM, Greg Grossmeier greg@wikimedia.org wrote:
<quote name="Alex Monk" date="2016-01-28" time="19:07:09 +0000"> > On 28 January 2016 at 18:53, Rob Lanphier <robla@wikimedia.org> wrote: > > > 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.) > > > > > > > Awww....you're mail was so great, and then you ended with this! Are you > > saying that the only real power in this world belongs to people with > > control of the money? > > > 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.
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.
Also, Wes Moran gave the keynote, and didn't say anything to contradict what I said in my email. Is there something I missed there?
Generally speaking, the position WMF executive management has taken in the conversations that I've had is that WMF needs to do a better job listening to the community. Saying that ArchCom has "no say" basically is taking a needlessly fatalistic stance of a mindless wage slave. I know y'all well enough to know that everyone on this thread is intensely mission-driven, and "mindless" is about as far from a truthful description anyone could give.
ArchCom strives to define what we should do, based on listening to the community and using our collective expertise to craft a vision based on what we learn. What "WMF senior leadership" (pls define) does with that information is probably not in scope for this mailing list.
Rob _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
<quote name="Wes Moran" date="2016-01-28" time="18:34:30 -0500">
Yeah I was there and enjoyed it, thanks again Rob and Quim. There were many good discussions that help us align and structure the thinking. It takes a lot of thought, data and discussion to know what to build, before you make the commitment to build it. At the dev summit many of the teams that influence budget allocation (Ideally a participatory process, not management alone) participated and are active in proposals. The review and cross team discussions on efforts like the Community Wishlist, Dev Summit Proposals and ArchCom are considered by teams on a regular basis and then put into the planning of where resources align.
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
On Thu, Jan 28, 2016 at 10:53:27AM -0800, Rob Lanphier wrote:
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.)
Awww....you're mail was so great, and then you ended with this! Are you saying that the only real power in this world belongs to people with control of the money?
That's kinda stretching what I said, doesn't it :)
What I'm saying is that there is a (probably unavoidable) disconnect between the ArchComm's and WMF's (or WMDE's, or other orgs' for that matter) decision processes and cadences.
The ArchComm isn't in the path of resourcing and generally does not vet RfCs based on whether e.g. they are backed by fully-staffed teams (or even whether the required infrastructure for implementing them exists or can be procured, under our constraints). My understanding is also that as a purely technical body, it doesn't do much of a cost/benefit analysis either. The ArchComm thus tends to judge ideas on their merits and their merits alone -- and not unreasonably so.
This effectively means that some of the ArchComm-"approved" ideas may be unimplementable -- at least until some organization or department decides to foot the bill, possibly going via their budgeting process (which can even be on an annual basis), etc.
So -- yes, I think there is a particular amount of "power" that the ArchComm doesn't have and cannot really have; I don't think that's a problem per se, but I do think it needs to be recognized and planned for. This could example be to generally limit the scope of the committee (e.g. to architecture direction and not feature planning; or to MediaWiki/software architecture and not infrastructure planning, etc.) and/or by ensuring budget owners are attending and influencing the decision-making process.
Faidon
Hi Rob,
"@Robla-WMF : Can you please clarify the first sentence "We now MediaWiki-RfCs and RfC, which now greatly complicates being able to rename "mediawiki-rfcs" " ... in this https://phabricator.wikimedia.org/T124255 ? "
Cheers, Scott
On Fri, Jan 22, 2016 at 2:03 PM, Rob Lanphier robla@wikimedia.org wrote:
Hi everyone,
Those with a keen eye will notice that I filed T124255 https://phabricator.wikimedia.org/T124255, which calls for renaming #MediaWIki-RfCs in Phab to "#ArchCom-RfC". This would be a boring Phab administrivia email if it was simply that.
The reason I want the rename: ArchCom is the mechanism we hope to ensure we build and deploy increasingly excellent software on the Wikimedia production cluster in a consensus-oriented manner. MediaWiki is at the center of this, but ArchCom's responsibility doesn't end with MediaWiki.
T124255 https://phabricator.wikimedia.org/T124255 is an odd place to have a more sweeping conversation about the scope of ArchCom, but it'll do for now. Feel free to comment there or on this mailing list.
Thanks Rob _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 01/22/2016 05:03 PM, Rob Lanphier wrote:
Hi everyone,
Those with a keen eye will notice that I filed T124255 https://phabricator.wikimedia.org/T124255, which calls for renaming #MediaWIki-RfCs in Phab to "#ArchCom-RfC". This would be a boring Phab administrivia email if it was simply that.
The reason I want the rename: ArchCom is the mechanism we hope to ensure we build and deploy increasingly excellent software on the Wikimedia production cluster in a consensus-oriented manner. MediaWiki is at the center of this, but ArchCom's responsibility doesn't end with MediaWiki.
In my opinion, there needs to be a group leading development of MediaWiki itself, focusing on the product and the product roadmap (influenced by who uses it). WMF is a critically important user of MW, but not the only one.
There should also be a group employed by WMF responsible for keeping track of what ends up on the WMF cluster. Obviously, the WMF cluster group would have a heavy influence on the MW roadmap, and they should not be surprised by anything happening in MW.
Nevertheless, they are separate focuses, and I would suggest we might want them to be separate groups. The group in charge of MW's roadmap would not have to care about things like major operations/puppet restructuring, while the WMF cluster group would.
(Note, this is related to the discussions about MediaWiki Foundation, but doesn't need to wait on that).
Matt Flaschen
On Mon, Jan 25, 2016 at 9:59 AM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 01/22/2016 05:03 PM, Rob Lanphier wrote:
The reason I want the rename [in T124255 https://phabricator.wikimedia.org/T124255]: ArchCom is the mechanism we hope to ensure
we build and deploy increasingly excellent software on the Wikimedia
production cluster in a consensus-oriented manner. MediaWiki is at the center of this, but ArchCom's responsibility doesn't end with MediaWiki.
In my opinion, there needs to be a group leading development of MediaWiki itself, focusing on the product and the product roadmap (influenced by who uses it). WMF is a critically important user of MW, but not the only one. [...] I would suggest we might want them to be separate groups. The group in charge of MW's roadmap would not have to care about things like major operations/puppet restructuring, while the WMF cluster group would.
(Note, this is related to the discussions about MediaWiki Foundation, but doesn't need to wait on that).
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
Hi Rob, Matt and All,
CC World University and School, potentially planning to develop with MediaWiki in all of Wikipedia's ~ 300 languages, plus the remaining 7,638 other ones, would consider being part of this Architecture Committee subgroup, or forked group. (CC WUaS is like CC Wikipedia/Wikidata with best STEM CC OCW such as CC MIT OCW in 7 languages and CC Yale OYC) and planning to develop accrediting CC universities' in all countries' main languages and wiki schools in all 7,938 languages). Thanks.
Scott
On Mon, Jan 25, 2016 at 12:16 PM, Rob Lanphier robla@wikimedia.org wrote:
On Mon, Jan 25, 2016 at 9:59 AM, Matthew Flaschen <mflaschen@wikimedia.org
wrote:
On 01/22/2016 05:03 PM, Rob Lanphier wrote:
The reason I want the rename [in T124255 https://phabricator.wikimedia.org/T124255]: ArchCom is the mechanism we hope to ensure
we build and deploy increasingly excellent software on the Wikimedia
production cluster in a consensus-oriented manner. MediaWiki is at the center of this, but ArchCom's responsibility doesn't end with MediaWiki.
In my opinion, there needs to be a group leading development of MediaWiki itself, focusing on the product and the product roadmap (influenced by
who
uses it). WMF is a critically important user of MW, but not the only
one.
[...] I would suggest we might want them to be separate groups. The
group
in charge of MW's roadmap would not have to care about things like major operations/puppet restructuring, while the WMF cluster group would.
(Note, this is related to the discussions about MediaWiki Foundation, but doesn't need to wait on that).
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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Jan 25, 2016 at 3:16 PM, Rob Lanphier robla@wikimedia.org wrote:
So: forks welcome! Any takers?
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).
On Mon, Jan 25, 2016 at 4:06 PM, C. Scott Ananian cananian@wikimedia.org wrote:
On Mon, Jan 25, 2016 at 3:16 PM, Rob Lanphier robla@wikimedia.org wrote:
So: forks welcome! Any takers?
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".
You seem to be assuming that "fork" === "complete rewrite". That's not necessarily the case, nor is it necessarily even desirable.
On Mon, Jan 25, 2016 at 4:27 PM, Brad Jorsch (Anomie) <bjorsch@wikimedia.org
wrote:
On Mon, Jan 25, 2016 at 4:06 PM, C. Scott Ananian cananian@wikimedia.org wrote:
On Mon, Jan 25, 2016 at 3:16 PM, Rob Lanphier robla@wikimedia.org
wrote:
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 25 January 2016 at 20:16, Rob Lanphier robla@wikimedia.org wrote:
So: forks welcome! Any takers?
At this point I'm not sure any non-Wikimedia MediaWiki contributors have the resources to do so. I think WMF employs most of the main MW developers, and probably does >50% of the development.
On 25 January 2016 at 20:16, Rob Lanphier robla@wikimedia.org wrote:
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.
On 25 January 2016 at 20:16, Rob Lanphier robla@wikimedia.org wrote:
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.
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 ;-)
So Wikimedia would keep the MediaWiki trademark and no longer have to worry about supporting 'third parties', and presumably most of the MW code actively being developed by Wikimedia would no longer be expected to run outside of WMF production/beta cluster/developer's laptops? I assume you'd merge MediaWiki.org into wikitech.wikimedia.org and copy the non-Wikimedia-specific stuff to be imported into a new (non-WMF-hosted) wiki for the fork, controlled by the maintainers of the fork.
I'm picturing a situation whereby a (probably unlikely to be successful) fork is made, MediaWiki core (now entirely a Wikimedia thing) is changed to depend on various things such as external services (probably with various WMF-specific requirements/expectations), the fork never really takes off, and we're left with MediaWiki that no longer supports anyone but Wikimedia. That seems like quite a risk.
I like the idea of MediaWiki being a proper independent upstream, not just a fork that's set up to get 'third parties' out of the largest MW contributor's hair and then left to diverge significantly (to the point where WMF couldn't simply migrate on the normal deployment branching schedule) and/or die.
On 25 January 2016 at 20:16, Rob Lanphier robla@wikimedia.org wrote:
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
I'm not sure anyone is pressuring WMF into putting resources into developing new things only 'third parties' need. Non-Wikimedia use of MediaWiki is already viable, and just like all other contributors, Wikimedia is expected to keep MW core reasonably generic enough such that it can be used by others, which seems to cause certain people within Wikimedia to want to get rid of everyone else so they can do their own thing. Didn't Wikia fork long ago?
On 01/25/2016 05:58 PM, Alex Monk wrote:
On 25 January 2016 at 20:16, Rob Lanphier robla@wikimedia.org wrote:
So: forks welcome! Any takers?
At this point I'm not sure any non-Wikimedia MediaWiki contributors have the resources to do so. I think WMF employs most of the main MW developers, and probably does >50% of the development.
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
On 01/25/2016 03:16 PM, Rob Lanphier wrote:
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.
Are there stats that show a decline? Just curious.
ArchCom's focus is (and should continue to be) the needs of Wikimedia.
Disagree, though if that is what ArchCom sees its role as, then we should make a separate committee that considers the overall roadmap of MW.
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.
This is very true, and these are good examples.
I'm a huge supporter of the right to fork, and if someone thinks that's the best solution, they should do it.
However, there are other examples where governance has successfully changed without a fork, such as Apache Cassandra.
There are also other examples of where there's a major user of the software (e.g. Wordpress.com) with downstream customizations, but powered by open source software also used by others (Wordpress proper).
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.
I disagree. There are a lot of kinds of knowledge, and a lot of ways to "freely share in the sum of all knowledge". Some of those ways are consistent with being part of a Wikimedia project (Wikipedia, Wiktionary, etc.).
Some other kinds of knowledge sharing could make good use of MediaWiki but *don't* belong on a Wikimedia project.
Licensing the MediaWiki trademark (maybe for a limited time at first, to make sure the other organization didn't mess it up) is consistent with the vision.
- Trusted architects with clear vision and leadership
Yes, and obviously this would include WMF employees, but not exclusively (in fact ArchCom already isn't only WMF).
- A governance structure that allows WMF to operate as a worthy peer
+1
So: forks welcome! Any takers?
None of this requires a fork.
(It also might turn out that we try this, it doesn't work, and it leads to a fork. But maybe that would mean it's the right solution after all. I think we should try it without a fork first, though.)
Matt Flaschen
Hi,
On 01/27/2016 12:46 PM, Matthew Flaschen wrote:
On 01/25/2016 03:16 PM, Rob Lanphier wrote:
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.
Are there stats that show a decline? Just curious.
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
On 28 January 2016 at 02:15, Legoktm legoktm.wikipedia@gmail.com wrote:
Hi,
On 01/27/2016 12:46 PM, Matthew Flaschen wrote:
On 01/25/2016 03:16 PM, Rob Lanphier wrote:
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.
Are there stats that show a decline? Just curious.
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...
Perhaps relevant, but that's not at all a complete picture of MediaWiki's use. MediaWiki is linked to at the bottom of every Wikipedia page, and a lot of interested users are going to be able to remember the domain name without going through Google. Download traffic (direct from mw.o, but also through OS package managers) would be a more useful indication.
wikitech-l@lists.wikimedia.org