Scope of ArchCom

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Scope of ArchCom

Rob Lanphier-4
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

Alex Monk
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 <[hidden email]> 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.
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

Rob Lanphier-4
 On Fri, Jan 22, 2016 at 2:08 PM, Alex Monk <[hidden email]> 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

Scott MacLeod
In reply to this post by Rob Lanphier-4
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 <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




--

- Scott MacLeod - Founder & President
- 415 480 4577
- http://scottmacleod.com
- Please donate to tax-exempt 501 (c) (3)
- World University and School
- via PayPal, or credit card, here -
- http://worlduniversityandschool.org
- or send checks to
- PO Box 442, (86 Ridgecrest Road), Canyon, CA 94516
- World University and School - like Wikipedia with best STEM-centric
OpenCourseWare - incorporated as a nonprofit university and school in
California, and is a U.S. 501 (c) (3) tax-exempt educational organization.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

C. Scott Ananian
In reply to this post by Rob Lanphier-4
On Fri, Jan 22, 2016 at 5:30 PM, Rob Lanphier <[hidden email]> wrote:

>  On Fri, Jan 22, 2016 at 2:08 PM, Alex Monk <[hidden email]> 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)
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

Rob Lanphier-4
On Fri, Jan 22, 2016 at 2:58 PM, C. Scott Ananian <[hidden email]>
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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

Matthew Flaschen-2
In reply to this post by Rob Lanphier-4
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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

Rob Lanphier-4
On Mon, Jan 25, 2016 at 9:59 AM, Matthew Flaschen <[hidden email]>
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

Scott MacLeod
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 <[hidden email]> wrote:

> On Mon, Jan 25, 2016 at 9:59 AM, Matthew Flaschen <[hidden email]
> >
> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



--

- Scott MacLeod - Founder & President
- 415 480 4577
- http://scottmacleod.com
- Please donate to tax-exempt 501 (c) (3)
- World University and School
- via PayPal, or credit card, here -
- http://worlduniversityandschool.org
- or send checks to
- PO Box 442, (86 Ridgecrest Road), Canyon, CA 94516
- World University and School - like Wikipedia with best STEM-centric
OpenCourseWare - incorporated as a nonprofit university and school in
California, and is a U.S. 501 (c) (3) tax-exempt educational organization.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

C. Scott Ananian
In reply to this post by Rob Lanphier-4
On Mon, Jan 25, 2016 at 3:16 PM, Rob Lanphier <[hidden email]> 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).

(http://cscott.net)
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

Brad Jorsch (Anomie)
On Mon, Jan 25, 2016 at 4:06 PM, C. Scott Ananian <[hidden email]>
wrote:

> On Mon, Jan 25, 2016 at 3:16 PM, Rob Lanphier <[hidden email]> 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.


--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

C. Scott Ananian
On Mon, Jan 25, 2016 at 4:27 PM, Brad Jorsch (Anomie) <[hidden email]
> wrote:

> On Mon, Jan 25, 2016 at 4:06 PM, C. Scott Ananian <[hidden email]>
> wrote:
>
> > On Mon, Jan 25, 2016 at 3:16 PM, Rob Lanphier <[hidden email]>
> 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

Alex Monk
In reply to this post by Rob Lanphier-4
 On 25 January 2016 at 20:16, Rob Lanphier <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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?
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

Matthew Flaschen-2
In reply to this post by Rob Lanphier-4
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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

Matthew Flaschen-2
In reply to this post by Alex Monk


On 01/25/2016 05:58 PM, Alex Monk wrote:
>   On 25 January 2016 at 20:16, Rob Lanphier <[hidden email]> 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

Legoktm
In reply to this post by Matthew Flaschen-2
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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

Alex Monk
On 28 January 2016 at 02:15, Legoktm <[hidden email]> 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&tz=Etc%2FGMT-11
> >
>

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 mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

Faidon Liambotis
In reply to this post by Rob Lanphier-4
On Fri, Jan 22, 2016 at 02:30:22PM -0800, Rob Lanphier wrote:

>  On Fri, Jan 22, 2016 at 2:08 PM, Alex Monk <[hidden email]> 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

Rob Lanphier-4
Thanks for articulating this very clearly Faidon!  More inline...

On Thu, Jan 28, 2016 at 3:11 AM, Faidon Liambotis <[hidden email]>
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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Scope of ArchCom

Alex Monk
On 28 January 2016 at 18:53, Rob Lanphier <[hidden email]> 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.
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12