[Wikitech-l] New [[Main Page]] for Wikitech

[Bryan Davis]

I've been working on a little redesign project for the Main Page on
wikitech [0] and three key sub pages it points to since 2016-01-01 in
my User space. Tonight I decided that although it is far from perfect
it is better enough. I hope that some of you like it better than the
old page and that none of you hate it with a fiery passion that
compels you to revert it rather than helping me make it better.

[0]: https://wikitech.wikimedia.org/wiki/Main_Page

Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

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

[Wikitech-l] PHP-side breaking changes to login and account creation tokens in 1.27.0-wmf.12

[Brad Jorsch (Anomie)]

With the merge of Gerrit change 264309,[1] to be deployed with
1.27.0-wmf.12, note the following changes to the PHP interface around login
and account creation tokens:

   - LoginForm::setLoginToken() and LoginForm::setCreateaccountToken() are
   deprecated and no longer do anything. The token is automatically created
   when fetched.
   - LoginForm::getLoginToken() and LoginForm::getCreateaccountToken() now
   return a MediaWiki\Session\Token object rather than a string. This object
   implements __toString(), so automatic casting to a string is supported and
   will likely mask this change for many uses.
   - The token strings themselves are now similar to edit tokens: they're
   longer, end in "+\", and include an embedded timestamp for expiration.
   - Due to the embedded timestamp, tokens must now be compared using the
   ->match() method on the Token object. String equality comparison will no
   longer work.
   - It is no longer possible to determine if the token was not already
   generated for the session by looking for an empty response from
   LoginForm::getLoginToken() and LoginForm::getCreateaccountToken(). If
   this is necssary (it shouldn't be), use the ->wasNew() method on the Token
   object.

If your PHP code makes use of login or account creation tokens for some
reason, please check to see if your code needs updating for these changes.

For the record, a new method User::getEditTokenObject() has been added to
fetch edit tokens as MediaWiki\Session\Token objects as well, but
User::getEditToken() and User::matchEditToken() have not been changed or
deprecated at this time.

Note that API clients and other non-PHP users of these tokens are unlikely
to be broken by this change. See
https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-January/000102.html
for details on changes to the API related to this change.

 [1]: https://gerrit.wikimedia.org/r/#/c/264309/

-- 
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] [Engineering] New [[Main Page]] for Wikitech

[Dan Garry]

On 28 January 2016 at 21:55, Bryan Davis  wrote:

> I've been working on a little redesign project for the Main Page on
> wikitech [0] and three key sub pages it points to since 2016-01-01 in
> my User space. Tonight I decided that although it is far from perfect
> it is better enough. I hope that some of you like it better than the
> old page and that none of you hate it with a fiery passion that
> compels you to revert it rather than helping me make it better.
>

Thank you! The new page is a clear improvement over the old one
.

Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New [[Main Page]] for Wikitech

[Derk-Jan Hartman]

This is awesome Bryan !

DJ

> On 29 jan. 2016, at 06:55, Bryan Davis  wrote:
> 
> I've been working on a little redesign project for the Main Page on
> wikitech [0] and three key sub pages it points to since 2016-01-01 in
> my User space. Tonight I decided that although it is far from perfect
> it is better enough. I hope that some of you like it better than the
> old page and that none of you hate it with a fiery passion that
> compels you to revert it rather than helping me make it better.
> 
> [0]: https://wikitech.wikimedia.org/wiki/Main_Page
> 
> Bryan
> --
> Bryan Davis  Wikimedia Foundation
> [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
> irc: bd808v:415.839.6885 x6855
> 
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Close test2wiki?

[Dan Garry]

On 27 January 2016 at 22:51, Ori Livneh  wrote:
>
> Ok, understood. Keeping it around costs little. Dan, in case you were
> volunteering, please go ahead and document the purpose of test2 on its main
> page and/or wikitech -- I think it is a good idea.
>

I would be happy to!

I made some changes

to the main page of test2. I also made some changes

to the test2 page on wikitech. Feel free to review and improve.

Thanks,
Dan

-- 
Dan Garry
Lead Product Manager, Discovery
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Google Code-in 2015 is over. Congratulations everybody!

[Andre Klapper]

Google Code-in 2015 has come to an end.

Thanks to our students for resolving 461 Wikimedia tasks. Thanks to our
35 mentors for being available, also on weekends & holidays. Thanks to
everybody on IRC for your friendliness, patience, and help provided to
new contributors.

Some more achievements, apart from those already mentioned in
https://lists.wikimedia.org/pipermail/wikitech-l/2015-December/084421.html :

 * The CommonsMetadata extension parses vcards in the src field
 * The MediaWiki core API exposes "actual watchers" as in "action=info"
 * MediaWiki image thumbnails are interlaced whenever possible
 * Kiwix is installable/moveable to the SD card, automatically opens
   the virtual keyboard for "find in page", (re)starts with the last
   open article
 * imageinfo queries in MultimediaViewer are cached
 * Twinkle's set of article maintenance tags was audited and its XFD
   module has preview functionality
 * The RandomRootPage extension got merged into MediaWiki core
 * One can remove items from Gather collections
 * A new MediaWiki maintenance script imports content from text files
 * Pywikibot has action=mergehistory support implemented
 * Huggle makes a tone when someone writes something
 * Many i18n issues fixed and strings improved
 * Namespace aliases added to MediaWiki's export dumps
 * The Translate extension is compatible with PHP 7

The Grand Prize winners & finalists will be announced on February 8th.

Again congratulations everybody, and thanks for the hard work.

See you around on IRC, mailing lists, Gerrit, and Phabricator!

Cheers,
andre

-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/



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

Re: [Wikitech-l] Close test2wiki?

[Rob Lanphier]

On Wed, Jan 27, 2016 at 10:51 PM, Ori Livneh  wrote:

> Ok, understood. Keeping it around costs little. Dan, in case you were
> volunteering, please go ahead and document the purpose of test2 on its main
> page and/or wikitech -- I think it is a good idea.
>
> If it is cheap to keep it, why did I even bother asking? I'm glad you
> asked!
>
> As the Wikimedia software stack evolves, some of its components become
> vestigial. Their existence makes it harder for anyone to form a systematic
> understanding of the whole, because they don't have any clear functional
> relationships with others components. And since they're not on anybody's
> mind, they have a tendency to become "gotchas" for future upgrades and
> migrations. So it's good to get rid of them, even if the resource costs are
> small.


Hi Ori,

Thanks for bringing this seemingly vestigial weirdness to our attention.
As you say, it should be documented better.

As I'm reading this, you are still making the case that we should still
shut this down.  Given the amount of mailing list traffic this has
generated, not everyone agrees.  Rather than continuing this conversation
on wikitech-l, could you file a Phab task for this (e.g. "Decommission
test2.wikipedia.org"), and direct the conversation there?  That will help
people who care about this topic not only have a more focused audience for
their comments, but will also give us a good way of tracking all of the
things Phab tasks typically track (e.g. owner, priority, dependencies,
resolution)

Rob
___
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] Developer Relations Weekly Summary

[Pine W]

Hi Quim,

Is there, or will there be, a page somewhere that describes the outcomes of
the Developer Summit?

Thanks!
Pine

On Thu, Jan 28, 2016 at 6:19 AM, Quim Gil  wrote:

> The Winter break took longer than expected. Busy times!
>
> You can help develop the next summary.
>
> *Developer Relations focus*
>
> * Wrapping up Google Code-in 2015
> * Wikimedia Hackathon 2016 travel sponsorship requests
> * Wikimedia Developer Summit 2016/Lessons Learned
> * Developer Relations strategy and annual plan
>
> There is a lot more at
>
> https://www.mediawiki.org/wiki/Developer_Relations/Weekly_summary#2016-01-26
>
> --
> Quim Gil
> Engineering Community Manager @ Wikimedia Foundation
> http://www.mediawiki.org/wiki/User:Qgil
> ___
> 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] Close test2wiki?

[Ori Livneh]

On Thu, Jan 28, 2016 at 11:06 AM, Rob Lanphier  wrote:

> Hi Ori,
>
> Thanks for bringing this seemingly vestigial weirdness to our attention.
> As you say, it should be documented better.
>
> As I'm reading this, you are still making the case that we should still
> shut this down.


Sorry, I should have  been clearer. Given the responses (which identified
clear and reasonable use-cases), I think it's perfectly fine to keep it
around. I just wanted to explain why I bothered asking in the first place.
___
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] Changes in the RFC decision making process

[Scott MacLeod]

Congratulations for these big "process" steps - great!

Scott



On Thu, Jan 28, 2016 at 5:25 PM, Gabriel Wicke  wrote:

> In the last weeks we have been exploring ways to improve our technical
> consensus building and decision making process. I wrote a short RFC
> [1] describing some issues, and proposed to adopt ideas from the Rust
> community [2] to address them. The discussion on the task and in an
> IRC meeting showed broad support for the proposals.
>
> In yesterday's architecture committee meeting, we decided to adopt
> much of the Rust RFC decision making process [3] on a trial basis.
> Concretely, this means:
>
> - We will nominate a member of the architecture committee as a
> shepherd, guiding an active RFC through the process. Among other
> things, the shepherd is responsible for informing all relevant
> stakeholders of the ongoing discussion on the task. The shepherd might
> also lead an IRC discussion on the RFC, which will be summarized on
> the task.
>
> - Once the discussion on a task plateaus or stalls, the shepherd (in
> coordination with the RFC author(s)) announces and widely publicizes a
> "Final Comment Period", which is one week.
>
> - At the end of the "Final Comment Period", the architecture committee
> decides based on the points made in the RFC discussion, and justifies
> its decision based on the overall project principles and priorities.
> If any new facts or aspects are surfaced in this discussion, a new
> Final Comment Period needs to be started before making a decision.
>
> For now, we are holding off on the second part of the RFC, the
> introduction of working groups. There is agreement that we need to
> broaden the involvement and scale the process, but the details of how
> are still under discussion.
>
> Gabriel
>
> [1]: https://www.mediawiki.org/wiki/Requests_for_comment/Governance
> [2]:
> https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md
> [3]:
> https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md#decision-making
>
> ___
> 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

[Wikitech-l] releases.wikimedia.org server has moved

[Daniel Zahn]

TLDR: The backend server used for releases.wikimedia.org has moved.
 use bromine.eqiad.wmnet instead of caesium.eqiad.wmnet

Do i care? You do if you are a "releaser" in one of the admin groups
who upload files to releases.wm.org.

Hi,

the backend of releases.wm.org has moved away from caesium.eqiad.wmnet over
to bromine.eqiad.wmnet.   The reason was to get rid of yet another outdated
Ubuntu system and replace it with a Debian jessie system.


All the releases files in /srv/org and your /home directories have been
copied over,
everything should be like before, just use the new server name please.

The task for that was https://phabricator.wikimedia.org/T124261

While on it i made the directory index page look a bit nicer and sort
files differently so that new release versions are on top.

The details for that were in https://phabricator.wikimedia.org/T125164

Let me know if you see any issues,

Best, Daniel

-- 
Daniel Zahn 
Operations Engineer
___
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

[Wikitech-l] Changes in the RFC decision making process

[Gabriel Wicke]

In the last weeks we have been exploring ways to improve our technical
consensus building and decision making process. I wrote a short RFC
[1] describing some issues, and proposed to adopt ideas from the Rust
community [2] to address them. The discussion on the task and in an
IRC meeting showed broad support for the proposals.

In yesterday's architecture committee meeting, we decided to adopt
much of the Rust RFC decision making process [3] on a trial basis.
Concretely, this means:

- We will nominate a member of the architecture committee as a
shepherd, guiding an active RFC through the process. Among other
things, the shepherd is responsible for informing all relevant
stakeholders of the ongoing discussion on the task. The shepherd might
also lead an IRC discussion on the RFC, which will be summarized on
the task.

- Once the discussion on a task plateaus or stalls, the shepherd (in
coordination with the RFC author(s)) announces and widely publicizes a
"Final Comment Period", which is one week.

- At the end of the "Final Comment Period", the architecture committee
decides based on the points made in the RFC discussion, and justifies
its decision based on the overall project principles and priorities.
If any new facts or aspects are surfaced in this discussion, a new
Final Comment Period needs to be started before making a decision.

For now, we are holding off on the second part of the RFC, the
introduction of working groups. There is agreement that we need to
broaden the involvement and scale the process, but the details of how
are still under discussion.

Gabriel

[1]: https://www.mediawiki.org/wiki/Requests_for_comment/Governance
[2]: https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md
[3]: 
https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md#decision-making

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

Re: [Wikitech-l] Fwd: Your speaking schedule at FOSDEM

[Ricordisamoa]

I do understand that the conversion has been challenging.
However, I also believe that Flow shouldn't be misrepresented as a 
complete success on behalf of the MediaWiki community, when its 
development has been in fact halted, it is missing critical features and 
one of the biggest independent users of LiquidThreads is still to make 
the leap.


Il 17/01/2016 18:28, Maarten Dammers ha scritto:

Op 17-1-2016 om 8:23 schreef Ricordisamoa:
Or "Converting talk pages from an unmaintained system to a halted 
one" :-D

Not cool Ricordisamoa.

Thanks Matt for putting effort into this. For anyone who will be at 
FOSDEM: Please add yourself to https://phabricator.wikimedia.org/E52 
(if you haven't done already)


Maarten



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

Re: [Wikitech-l] Close test2wiki?

[Ricordisamoa]

Il 28/01/2016 02:30, Dan Garry ha scritto:

On 27 January 2016 at 17:16, Legoktm  wrote:


Especially when debugging and testing cross-wiki features, it is
extremely useful to have two test wikis to use. MassMessage,
GlobalCssJs, GlobalUserPage, and now cross-wiki notifications were all
initially deployed using testwiki as the "central" wiki, and test2wiki
as a "client" wiki.


That sounds like a good reason to keep it, especially since global
notifications is an active, ongoing work. Perhaps, as an alternative to
shutting it down, we should just make it clearer that test2.wikipedia.org
is primarily intended for that purpose on that wiki's main page (or
anywhere else thought appropriate). If there's some specific overhead to
keeping test2 alive that might outweigh that benefit, now would seem to be
the time to make it clear. :-)

Dan



I second Legoktm's comment. And, for what it's worth, I don't think it 
makes much sense to limit test2wiki to a specific purpose.


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

Re: [Wikitech-l] Close test2wiki?

[aude]

On Jan 27, 2016 9:57 PM, "Ori Livneh"  wrote:
>
> The setup of test2.wikipedia.org is no longer meaningfully different from
> test.wikipedia.org. Is there a good reason for keeping test2?

test2 is used a bit for testing wikibase client stuff like for lua
templates. Forget why but test2 has had wikibase client long before it was
enabled on test Wikipedia.

As wikidata developer, when we roll out new features like arbitrary access,
I also like to have one test Wikipedia with it and one without (while some
wikipedias don't have said feature yet). Helps if we need to debug one or
other setup, or if a bug sneaks by all our phpunit etc tests and beta and
affects one of the configurations, then test + test2 can help.

I don't think there is so much extra maintenance burden of having test2
around to justify closing it, vs benefits it can give.
Cheers,
Katie


> ___
> 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] Close test2wiki?

[Ori Livneh]

On Wed, Jan 27, 2016 at 10:17 PM, Ricordisamoa  wrote:

> Il 28/01/2016 02:30, Dan Garry ha scritto:
>
>> On 27 January 2016 at 17:16, Legoktm  wrote:
>>
>> Especially when debugging and testing cross-wiki features, it is
>>> extremely useful to have two test wikis to use. MassMessage,
>>> GlobalCssJs, GlobalUserPage, and now cross-wiki notifications were all
>>> initially deployed using testwiki as the "central" wiki, and test2wiki
>>> as a "client" wiki.
>>>
>>> That sounds like a good reason to keep it, especially since global
>> notifications is an active, ongoing work. Perhaps, as an alternative to
>> shutting it down, we should just make it clearer that test2.wikipedia.org
>> is primarily intended for that purpose on that wiki's main page (or
>> anywhere else thought appropriate). If there's some specific overhead to
>> keeping test2 alive that might outweigh that benefit, now would seem to be
>> the time to make it clear. :-)
>>
>> Dan
>>
>>
> I second Legoktm's comment. And, for what it's worth, I don't think it
> makes much sense to limit test2wiki to a specific purpose.


Ok, understood. Keeping it around costs little. Dan, in case you were
volunteering, please go ahead and document the purpose of test2 on its main
page and/or wikitech -- I think it is a good idea.

If it is cheap to keep it, why did I even bother asking? I'm glad you asked!

As the Wikimedia software stack evolves, some of its components become
vestigial. Their existence makes it harder for anyone to form a systematic
understanding of the whole, because they don't have any clear functional
relationships with others components. And since they're not on anybody's
mind, they have a tendency to become "gotchas" for future upgrades and
migrations. So it's good to get rid of them, even if the resource costs are
small.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] INFO: Reading web release process update

[Joaquin Oltra Hernandez]

On Wed, Jan 27, 2016 at 6:27 PM, Greg Grossmeier  wrote:

> 
> > Feature flagging or using feature branches for certain things may be a
> way
> > to go for certain things, we're keeping that in mind definitely, thanks
> for
> > the reminder Greg.
>
> Just be clear: feature branches aren't feature flags and take you back
> to a place closer to a 'dev' branch :).
>
>
Sure! I was just pointing out two other options that could be considered
depending on tradeoffs.


> > I agree with you regarding releases Gergo. The good thing about the
> > *release*s was mainly the curated changelog of changes for that release.
> A
> > proposal I like is do the changelog every week with the train before the
> > release branch is done. We'll need to establish owners for being
> effective
> > at doing that.
>
> It looks like the release notes[0] are just git short logs, yes? Or is
> the HISTORY file not what you are referring to (I only did a quick
> look)?
>
> If it is just the git shortlog, take a look here:
> eg: https://www.mediawiki.org/wiki/MediaWiki_1.27/wmf.11#MobileFrontend
>
> Those pages are automatically created and posted every week with the
> train, for free (by RelEng).
>

Nice, we were doing a filtered git log
 so
that's going to work just fine.

Thanks for the help Greg.


> 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
>
___
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

[Wikitech-l] (no subject)

[イノウエナオキ]

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

[Wikitech-l] Developer Relations Weekly Summary

[Quim Gil]

The Winter break took longer than expected. Busy times!

You can help develop the next summary.

*Developer Relations focus*

* Wrapping up Google Code-in 2015
* Wikimedia Hackathon 2016 travel sponsorship requests
* Wikimedia Developer Summit 2016/Lessons Learned
* Developer Relations strategy and annual plan

There is a lot more at
https://www.mediawiki.org/wiki/Developer_Relations/Weekly_summary#2016-01-26

-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l