Re: [Wikitech-l] [Wikimedia-l] First _draft_ goals for WMF engineering/product

[Nathan]

On Mon, Jun 9, 2014 at 9:24 PM, Erik Moeller  wrote:

> Hi all,
>
> We've got the first DRAFT (sorry for shouting, but can't hurt to
> emphasize :)) of the annual goals for the engineering/product
> department up on mediawiki.org. We're now mid-point in the process,
> and will finalize through June.
>
> https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals
>
> Note that at this point in the process, teams have flagged
> inter-dependencies, but they've not necessarily been taken into
> account across the board, i.e. team A may say "We depend on X from
> team B" and team B may not have sufficiently accounted for X in its
> goals. :P Identifying common themes, shared dependencies, and
> counteracting silo tendencies is the main focus of the coming weeks.
> We may also add whole new sections for cross-functional efforts not
> currently reflected (e.g. UX standardization). Site performance will
> likely get its own section as well.
>
> My own focus will be on fleshing out the overall narrative, aligning
> around organization-wide objectives, and helping to manage scope.
>
> As far as quantitative targets are concerned, we will aim to set them
> where we have solid baselines and some prior experience to work with
> (a good example is Wikipedia Zero, where we now have lots of data to
> build targets from). Otherwise, though, our goal should be to _obtain_
> metrics that we want to track and build targets from. This, in itself,
> is a goal that needs to be reflected, including expectations e.g. from
> Analytics.
>
> Like last year, these goals won't be set in stone. At least on a
> quarterly basis, we'll update them to reflect what we're learning.
> Some areas (e.g. scary new features like Flow) are more likely to be
> significantly revised than others.
>
> With this in mind: Please leave any comments/questions on the talk
> page (not here). Collectively we're smarter than on our own, so we do
> appreciate honest feedback:
>
> - What are our blind spots? Obvious, really high priority things we're
> not paying sufficient attention to?
>
> - Where are we taking on too much? Which projects/goals make no sense
> to you and require a stronger rationale, if they're to be undertaken at
> all?
>
> - Which projects are a Big Deal from a community perspective, or from
> an architecture perspective, and need to be carefully coordinated?
>
> These are all conversations we'll have in coming weeks, but public
> feedback is very helpful and may trigger conversations that otherwise
> wouldn't happen.
>
> Please also help to carry this conversation into the wikis in coming
> weeks. Again, this won't be the only opportunity to influence, and
> I'll be thinking more about how the quarterly review process can also
> account for community feedback.
>
> Warmly,
>
> Erik
>


Hi Erik,

Can you describe how specific engineering projects are helping to address
the gender gap? Do you typically review user-facing projects with the
gender gap specifically in mind? I notice that while there is a FOSS
outreach program for women, there is nothing specific in the Wikimania
Hackathon materials to suggest that an effort was made to attract women to
this event. There is another hackathon planned for early next year - will
engineering make the gender gap part of the goals of that event?

I also notice that the editor engagement projects don't specifically list
the gender gap or women users. I think that testing new features (such as
communication tools, notifications, teahouse-style innovations and others
that bear specifically on interactions) with female user/focus groups would
greatly improve our understanding of how these tools impact the gender gap.
For example:  If part of the plan for the growth team is to invite
anonymous editors to sign up, why not tailor some of those invitations
specifically to female anonymous editors? Then you could add a measure,
retention of female editors, to that particular growth project. The results
should be instructive.

Likewise, it would be nice to see gender-gap related goals within
VisualEditor and the user experience groups goals, and to see some focus
from the Analytics and Research teams on measuring and understanding the
gap better. Needless to say its a little disappointing that the FOSS
outreach program (which currently has 8 participants) is the only mention
of women in the entire goals document, and the gender gap is never
mentioned.

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

[Wikitech-l] dumps.wikimedia.org, downloads.wikimedia.org downtime Thursday June 26 13.30 UTC

[Ariel T. Glenn]

dumps.wikimedia.org, downloads.wikimedia.org will be down on Thursday
June 26 from 13.30 UTC until 14.30 UTC.  While we expect the actual
downtime to be much less, we're blocking one hour just in case.

We will be moving it to a new rack in preparation for improved
bandwidth, and yes this mean raising download caps.

Services affected: dumps and pageview downloads, any other files hosted
on the server.

Dumps themselves will be stopped during the duration of the downtime.
They will be restarted as needed once the host is back on line.

Ariel


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

Re: [Wikitech-l] [Wikimedia-l] First _draft_ goals for WMF engineering/product

[Brian Wolff]

>  If part of the plan for the growth team is to invite
> anonymous editors to sign up, why not tailor some of those invitations
> specifically to female anonymous editors? Then you could add a measure,
> retention of female editors, to that particular growth project. The results
> should be instructive.

At the risk of biting into something contentious... How would that
work? What would the message say: "Have you considered creating an
account? Its free. Doubly recommended if you're a women!" I have
trouble imagining a gender-specific account creation invitation that
doesn't sound creepy.

Additionally, actually measuring success rates by gender would require
knowing people's gender. Its conceivable that requiring people to
disclose their gender could have a negative impact on the gender gap.
(Or maybe it wouldn't. I have no idea)

--bawolff

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

Re: [Wikitech-l] [Wikimedia-l] First _draft_ goals for WMF engineering/product

[Nathan]

On Mon, Jun 23, 2014 at 3:45 PM, Brian Wolff  wrote:

> >  If part of the plan for the growth team is to invite
> > anonymous editors to sign up, why not tailor some of those invitations
> > specifically to female anonymous editors? Then you could add a measure,
> > retention of female editors, to that particular growth project. The
> results
> > should be instructive.
>
> At the risk of biting into something contentious... How would that
> work? What would the message say: "Have you considered creating an
> account? Its free. Doubly recommended if you're a women!" I have
> trouble imagining a gender-specific account creation invitation that
> doesn't sound creepy.
>
> Additionally, actually measuring success rates by gender would require
> knowing people's gender. Its conceivable that requiring people to
> disclose their gender could have a negative impact on the gender gap.
> (Or maybe it wouldn't. I have no idea)
>
> --bawolff
>
> 



I'm not sure what the messaging is planned to look like, but an appeal
oriented towards women doesn't seem like an insurmountable obstacle. "Did
you know only 10% of Wikipedia editors are women? If you are a woman
reading this, we need your help!" And then you can track sign-ups through
that particular message, figuring that a substantial proportion of them
will actually be women.

And you could also ask, during sign-up, for people to self-identify
confidentially. "We're trying to increase the proportion of our fellow
editors who are women, would you mind telling us if you identify as female?
[Y/N]". And then don't publish that anywhere except in aggregate.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Ensure that user is logged in

[Matthew Flaschen]

On 06/19/2014 11:09 PM, Daniel Friesen wrote:

B) If we even have anything similar to Content-MD5 (I don't remember
seeing anything) it's optional and the clients most likely to have a
buffer bugs like that are going to be the ones that don't use it.


There is an optional md5 parameter in the API; see 
https://www.mediawiki.org/wiki/API:Edit#Parameters


Matt Flaschen


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

[Wikitech-l] iPad bugs we need to fix in VE

[Juliusz Gonera]

There are three important bugs that need to be fixed in VE before we can
move it to stable for tablets (specifically iPads). The first two were
added by me just today. The third was reported in May by Rummana and for
some odd reason had Jon assigned to it, although he has never worked on it
(I removed him).

Following Roan's suggestion I recorded videos on iOS simulator to
illustrate what is happening in each case (thanks to Monte for letting me
use his Macbook with up-to-date Xcode).

https://bugzilla.wikimedia.org/show_bug.cgi?id=66999
https://bugzilla.wikimedia.org/show_bug.cgi?id=67002
https://bugzilla.wikimedia.org/show_bug.cgi?id=65326

Let us (the mobile team) know if you need any help with those.

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

Re: [Wikitech-l] [Wikimedia-l] First _draft_ goals for WMF engineering/product

[Sumana Harihareswara]

(I'm not on wikimedia-l so this won't make it to that list unless someone
forwards it; please feel free.)

wikitech-l and
https://www.mediawiki.org/wiki/Talk:Wikimedia_Engineering/2014-15_Goals
seem like good places to talk about whether we should have
gendergap-related goals for Wikimedia Foundation engineering for 2014-2015.
To discuss whether particular we could add or modify specific bits of
functionality (e.g., the signup page, VE) to better appeal to
underrepresented groups and help them start contributing, I suggest we use
the Editor Engagement list:

https://lists.wikimedia.org/mailman/listinfo/ee

I also want to note that the new grant-funded project to gather better data
on the gender gap will produce a midpoint report in September-October of
2014, and a final report in January 2015. The researcher will gather and
aggregate data that Engineering could use: "This data may also be used to
guide the design of future interventions or technology enhancements that
seek to address the gap."

https://meta.wikimedia.org/wiki/Grants:IEG/Women_and_Wikipedia

So perhaps we could set up checkpoints for our engineering teams in October
and January to look at those reports and use the new data to inform their
work.

Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation


On Mon, Jun 23, 2014 at 10:28 AM, Nathan  wrote:

> On Mon, Jun 9, 2014 at 9:24 PM, Erik Moeller  wrote:
>
> > Hi all,
> >
> > We've got the first DRAFT (sorry for shouting, but can't hurt to
> > emphasize :)) of the annual goals for the engineering/product
> > department up on mediawiki.org. We're now mid-point in the process,
> > and will finalize through June.
> >
> > https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals
> >
> > Note that at this point in the process, teams have flagged
> > inter-dependencies, but they've not necessarily been taken into
> > account across the board, i.e. team A may say "We depend on X from
> > team B" and team B may not have sufficiently accounted for X in its
> > goals. :P Identifying common themes, shared dependencies, and
> > counteracting silo tendencies is the main focus of the coming weeks.
> > We may also add whole new sections for cross-functional efforts not
> > currently reflected (e.g. UX standardization). Site performance will
> > likely get its own section as well.
> >
> > My own focus will be on fleshing out the overall narrative, aligning
> > around organization-wide objectives, and helping to manage scope.
> >
> > As far as quantitative targets are concerned, we will aim to set them
> > where we have solid baselines and some prior experience to work with
> > (a good example is Wikipedia Zero, where we now have lots of data to
> > build targets from). Otherwise, though, our goal should be to _obtain_
> > metrics that we want to track and build targets from. This, in itself,
> > is a goal that needs to be reflected, including expectations e.g. from
> > Analytics.
> >
> > Like last year, these goals won't be set in stone. At least on a
> > quarterly basis, we'll update them to reflect what we're learning.
> > Some areas (e.g. scary new features like Flow) are more likely to be
> > significantly revised than others.
> >
> > With this in mind: Please leave any comments/questions on the talk
> > page (not here). Collectively we're smarter than on our own, so we do
> > appreciate honest feedback:
> >
> > - What are our blind spots? Obvious, really high priority things we're
> > not paying sufficient attention to?
> >
> > - Where are we taking on too much? Which projects/goals make no sense
> > to you and require a stronger rationale, if they're to be undertaken at
> > all?
> >
> > - Which projects are a Big Deal from a community perspective, or from
> > an architecture perspective, and need to be carefully coordinated?
> >
> > These are all conversations we'll have in coming weeks, but public
> > feedback is very helpful and may trigger conversations that otherwise
> > wouldn't happen.
> >
> > Please also help to carry this conversation into the wikis in coming
> > weeks. Again, this won't be the only opportunity to influence, and
> > I'll be thinking more about how the quarterly review process can also
> > account for community feedback.
> >
> > Warmly,
> >
> > Erik
> >
>
>
> Hi Erik,
>
> Can you describe how specific engineering projects are helping to address
> the gender gap? Do you typically review user-facing projects with the
> gender gap specifically in mind? I notice that while there is a FOSS
> outreach program for women, there is nothing specific in the Wikimania
> Hackathon materials to suggest that an effort was made to attract women to
> this event. There is another hackathon planned for early next year - will
> engineering make the gender gap part of the goals of that event?
>
> I also notice that the editor engagement projects don't specifically list
> the gender gap or women users. I think that testing new features (such as
> communication tools, notificatio

Re: [Wikitech-l] Unclear Meaning of $baseRevId in WikiPage::doEditContent

[Adam Wight]

On Fri, Jun 6, 2014 at 4:08 PM, Aaron Schulz  wrote:

> I suppose that naming scheme is reasonable.
>
> $contentsRevId sounds awkward, maybe $sourceRevId or $originRevId is
> better.
>

What about "rollbackRevId"?  I want the variable name to make its purpose
very clear.

-Adam


>
>
> --
> View this message in context:
> http://wikimedia.7.x6.nabble.com/Unclear-Meaning-of-baseRevId-in-WikiPage-doEditContent-tp5028661p5029674.html
> Sent from the Wikipedia Developers mailing list archive at Nabble.com.
>
> ___
> 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

[Wikitech-l] question about standardized thumbnail sizes

[Sumana Harihareswara]

I asked some folks about
​
https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizes
​.​
​Antoine​, the original author, said on the talk page:

"We had several mailing list discussion in 2012 / beginning of 2013
regarding optimizing the thumbnails rendering. That RFC is merely a summary
of the discussions and is intended to avoid repeating ourself on each
discussion. I am not leading the RFC by any mean, would be nice to have the
new multimedia team to take leadership there."

Gergo of the multimedia team has a question about whether he should start a
new RfC, and a question for Ops (below), which he said I could forward to
this list, so I'm doing so. :-)

​If we can settle this onlist, cool. Otherwise I'll be setting up an IRC
chat for later this week.​


Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation


On Fri, Jun 20, 2014 at 12:27 PM, Gergo Tisza  wrote:

>
> Hi Sumana!
>
> We are working on some form of standardized thumbnail sizes, but it is not
> exactly the same issue that is discussed in the RfC
> 
> .
>
> The problem we have ran into is that MediaViewer fits the image size to
> the browser window size (which means a huge variety of image sizes even
> when the browser window is fully enlarged, and practically infinite
> otherwise),
> but thumbnail rendering is very slow and waiting for it would result in a
> crappy user experience. We started using a list of standardized thumbnail
> sizes, so that MediaViewer always requests one of these sizes from the
> browser and rescales them with CSS, but even so the delay remains
> problematic for the first user who requests the image with a given bucket.
> To address that, we are working with ops towards automatically rendering
> the thumbnails in those sizes as soon as the image is uploaded.
>
> Another possibility related to standardized thumbnail sizes that we are
> exploring is to speed up the thumbnail generation for large images by
> having a list of sizes for which the thumbnail is pregenerated and always
> present, and resize one of those thumbnails instead of the original to
> generate the size requested by the user. The goal of this would be to avoid
> overloading the scalers when several large images need to be thumbnailed at
> the same time (GWToolset caused outages this way on a few occasions).
>
> I can create an RfC about one or both of the above issues if there is
> interest in wider discussion. I don't know whether the current thumbnail
> size standardization RfC should be replaced with those, though; its goals
> are not stated, but seem to be mainly operations concerns (how to make sure
> thumbnails don't take up too much storage space). Maybe ops wants to take
> it over, or provide clearer goals in that regard for the multimedia team to
> work towards.
>
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] MediaWiki Front-End Standardization Chat

[Sumana Harihareswara]

Added to https://www.mediawiki.org/wiki/Project:Calendar and
https://meta.wikimedia.org/wiki/IRC_office_hours#Upcoming_office_hours . :)

Sumana


On Thu, Jun 19, 2014 at 9:33 PM, Erik Moeller  wrote:

> Hi folks,
>
> We're hosting a conversation about standardization and continued
> development of front-end libraries in MW core on 6/25, 5:30 PM UTC,
> #wikimedia-office.
>
> This is driven by a recognized need for teams at WMF to work more
> effectively on user-facing features and reduce duplication of efforts
> and inconsistencies across extensions. We're willing to take a bit of
> a hit on the short term velocity of feature development to build a
> more robust, consistent and developer-friendly platform.
>
> Timo Tijhof, Trevor Parscal and Roan Kattouw have proposed a
> systematic effort to improve MW core's front-end libraries, building
> on existing efforts (see
> https://www.mediawiki.org/wiki/UX_standardization for a messy but
> reasonably comprehensive overview of some of the inconsistencies and
> wheel duplication we need to solve).
>
> This will be done in partnership with other interested front-end
> engineers across the org and the community.
>
> We'll try to come up with a clear scope of work, such as:
>
> - having Mobile and VisualEditor depend on the same front-end
> libraries in MW core and use them effectively
> - eliminating dependencies on jQuery UI from all WMF-deployed code, to
> be replaced with a MediaWiki-native look and feel
> - creating a proper living style guide and UX standardization pipeline
> in partnership with the WMF UX team.
>
> This conversation is just a first step to ensure this effort has
> visibility from the start, and major architectural changes will go
> through the usual public conversations.
>
> Thanks,
>
> Erik
>
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> ___
> 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