Re: [Wikitech-l] Scope of ArchCom

[Faidon Liambotis]

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.)
> 
> Awwwyou'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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Alex Monk]

On 28 January 2016 at 18:53, 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.)
> >
>
> Awwwyou'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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Alex Monk]

(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  wrote:

> On 28 January 2016 at 18:53, 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.)
>> >
>>
>> Awwwyou'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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Rob Lanphier]

Thanks for articulating this very clearly Faidon!  More inline...

On Thu, Jan 28, 2016 at 3:11 AM, Faidon Liambotis 
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
 (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 )

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
 that doesn't look right, a polite note to wikitech-l saying
"I'm confused about " 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
" 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.)
>

Awwwyou'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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Greg Grossmeier]

> On 28 January 2016 at 18:53, 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.)
> > >
> >
> > Awwwyou'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.

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Greg Grossmeier]

> 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

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Rob Lanphier]

On Thu, Jan 28, 2016 at 11:21 AM, Greg Grossmeier 
wrote:

> 
> > On 28 January 2016 at 18:53, 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.)
> > > >
> > >
> > > Awwwyou'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

Re: [Wikitech-l] Scope of ArchCom

[Wes Moran]

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  wrote:

> On Thu, Jan 28, 2016 at 11:21 AM, Greg Grossmeier 
> wrote:
>
> > 
> > > On 28 January 2016 at 18:53, 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.)
> > > > >
> > > >
> > > > Awwwyou'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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Greg Grossmeier]

> 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

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Faidon Liambotis]

On Fri, Jan 22, 2016 at 02:30:22PM -0800, Rob Lanphier wrote:
>  On Fri, Jan 22, 2016 at 2:08 PM, Alex Monk  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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Alex Monk]

On 28 January 2016 at 02:15, Legoktm  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=q=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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Legoktm]

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:


-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Matthew 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

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Matthew Flaschen]

On 01/25/2016 05:58 PM, Alex Monk wrote:

  On 25 January 2016 at 20:16, Rob Lanphier  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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Rob Lanphier]

On Mon, Jan 25, 2016 at 9:59 AM, Matthew Flaschen 
wrote:

> On 01/22/2016 05:03 PM, Rob Lanphier wrote:
>>
>> The reason I want the rename [in 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

Re: [Wikitech-l] Scope of ArchCom

[Matthew Flaschen]

On 01/22/2016 05:03 PM, Rob Lanphier wrote:

Hi everyone,

Those with a keen eye will notice that I filed 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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[C. Scott Ananian]

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

Re: [Wikitech-l] Scope of ArchCom

[Brad Jorsch (Anomie)]

On Mon, Jan 25, 2016 at 4:06 PM, C. Scott Ananian 
wrote:

> On Mon, Jan 25, 2016 at 3:16 PM, Rob Lanphier  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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 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  wrote:

> On Mon, Jan 25, 2016 at 9:59 AM, Matthew Flaschen  >
> wrote:
>
> > On 01/22/2016 05:03 PM, Rob Lanphier wrote:
> >>
> >> The reason I want the rename [in 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
>



-- 

- 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 

Re: [Wikitech-l] Scope of ArchCom

[C. Scott Ananian]

On Mon, Jan 25, 2016 at 4:27 PM, Brad Jorsch (Anomie)  wrote:

> On Mon, Jan 25, 2016 at 4:06 PM, C. Scott Ananian 
> wrote:
>
> > On Mon, Jan 25, 2016 at 3:16 PM, Rob Lanphier 
> 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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Alex Monk]

 On 25 January 2016 at 20:16, Rob Lanphier  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  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  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  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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Scope of ArchCom

[Rob Lanphier]

Hi everyone,

Those with a keen eye will notice that I filed 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  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

Re: [Wikitech-l] Scope of ArchCom

[Rob Lanphier]

 On Fri, Jan 22, 2016 at 2:08 PM, Alex Monk  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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[C. Scott Ananian]

On Fri, Jan 22, 2016 at 5:30 PM, Rob Lanphier  wrote:

>  On Fri, Jan 22, 2016 at 2:08 PM, Alex Monk  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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 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  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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Scott MacLeod]

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  wrote:

> Hi everyone,
>
> Those with a keen eye will notice that I filed 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  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




-- 

- 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
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Scope of ArchCom

[Rob Lanphier]

On Fri, Jan 22, 2016 at 2:58 PM, C. Scott Ananian 
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:


A relevant part to quote: "The Wikimedia Foundation
 legally controls the
servers; ultimately the Wikimedia Foundation 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 . 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 , 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
) before we start on the
administrative detail of what tags we want.

Rob
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l