Re: [Wikitech-l] ArchCom Monutes, News, and Outlook

[Legoktm]

Hi,

On 03/15/2017 03:58 PM, Gabriel Wicke wrote:
> Thanks for everyone who participated in the discussion. Unfortunately, we
> ran into a technical issue with setting up the youtube stream that we
> weren't able to resolve quickly (my apologies to those unable to follow the
> stream), but we did take detailed notes
> 
> that
> you can peruse and comment on.

As requested earlier, will these documents be moved to mediawiki.org or
is it now required to use Google's proprietary software to discuss the
architecture of MediaWiki?

-- Legoktm

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

Re: [Wikitech-l] ArchCom Monutes, News, and Outlook

[Gabriel Wicke]

Thanks for everyone who participated in the discussion. Unfortunately, we
ran into a technical issue with setting up the youtube stream that we
weren't able to resolve quickly (my apologies to those unable to follow the
stream), but we did take detailed notes

that
you can peruse and comment on.

As a next step, the Reading team will do some more research & document more
specifics on requirements and solutions. Following this, we will have
another round of discussion.

Thanks,

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

Re: [Wikitech-l] ArchCom Monutes, News, and Outlook

[Gabriel Wicke]

Reminder: this is about to start in a couple of minutes.


   - What: High level mobile frontend requirements & plans
  - Agenda / discussion notes
  

   - When: March 15, 2-3pm PDT (San Francisco)
   - Where:
  - Stream: http://youtu.be/8W7WrTa3Py4
  - Hangout (25 active participants max): https://hangouts.google.com
  /hangouts/_/ytl/T7sMtE_gUxWZ4biKxPh5ffreSnwnrIj1L7udZWXlKSk
  



On Tue, Mar 14, 2017 at 11:49 AM, Adam Baso  wrote:

> The doc is now public read.
>
> https://docs.google.com/document/d/1id-E_KELGGA3X5H4K44I6zIX3SEgZ0sF_
> biOY4INCqM
>
>
> On Fri, Mar 10, 2017 at 4:18 PM, Adam Baso  wrote:
>
> > I made a request to the document author for that, I imagine should be
> > available next week. Nothing secret in there, though.
> >
> > On Fri, Mar 10, 2017 at 4:16 PM, Legoktm 
> > wrote:
> >
> >> Hi,
> >>
> >> On 03/09/2017 08:17 AM, Daniel Kinzler wrote:
> >> > Next week’s RFC meeting (tentative, pending confirmation):
> >> > * explore High - Level Mobilefrontend Requirements (JavaScript
> >> frameworks,
> >> > Progressive Apps, and all that jazz)
> >> >  >> X3SEgZ0sF_biOY4INCqM/edit#heading=h.xs2aq4j4wzse>.
> >>
> >> I didn't try to open the link until now, but it requires a Google
> >> account to view, and is only visible to those in the WMF - could it be
> >> moved to mediawiki.org please?
> >
> >
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Gabriel Wicke
Principal Engineer, Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Please join the movement strategy conversation (now through April 15)

[Nicole Ebber]

Dear Wikimedians,

If you are a representative of an Affiliate, committee, or other
organized group in the Wikimedia Movement, please read this email
carefully and forward it to your peers.

I am writing you today in my role as the Movement Strategy Lead for
organized groups (Track A), and would like to encourage you to
actively participate in Wikimedia’s movement strategy process.
Together with you, we would like to find answers to the question “What
do we want to build or achieve together over the next 15 years?”
https://2030.wikimedia.org is the universal start page to the strategy
portal on Meta.

== This is our time! ==
This is the time many of us have been waiting for for years. I would
love to see each and every one of you make your voice heard and take
the chance to shape the future of our movement together.

== Timeline and process ==
The timeline up to Wikimania 2017 is organized in 3 consecutive
discussion cycles that are designed to explore, cluster and sharpen
the strategic direction and define 3-5 focus areas for the movement.
After Wikimania, we will discuss the movement structure, roles, as
well as 3-5-year goals and starting in 2018, organizations will
incorporate the findings into their strategic and annual planning.

Today, we are kicking off cycle 1 which is running until 15 April.
Organized groups will find all relevant information on the Meta page
for Track A.[1]

== Get involved! ==
Last week I reached out to all Chairs and EDs of Affiliates as well as
to active members of other organized groups and committees. While I
have heard from many, I would like to remind everyone to appoint a
discussion coordinator for your group that will act as the linker to
the strategy process.[2][3][4]

As an organized Group, you can invite all your stakeholders to join
your conversation: Board and staff members, members, external partners
and allies as well as members of your communities. Track A is closely
connected to Track B (Individual Contributors)[5], as many organized
Groups have close bonds with their local or thematic communities. We
encourage Track A and Track B coordinators to sync on their plans.

Your conversations can happen on- and offline. To host a conversation,
please read the discussion guide[6] that provides material to prepare,
conduct and document each conversation in each format. Before you and
your peers enter the conversation, please make yourself familiar with
the briefing[7] which provides a high-level overview of what we know
about the future and about our movement today.

I also look forward to seeing many of you at the Wikimedia Conference
in Berlin where we will discuss our future, generate thematic
statements, identify keywords and create thematic clusters of our
ideas. The rough outline of the program will be adjusted in the coming
days.[8]

Let’s make this happen! Please reach out to me with any question or
feedback you might have.

Sincerely,
Nicole


[1] 
https://meta.wikimedia.org/wiki/Special:MyLanguage/Strategy/Wikimedia_movement/2017/Track_A
[2] 
https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2017/Toolkit/Discussion_Coordinator_Role
[3] Sign-up to become a Discussion Coordinator here:
https://docs.google.com/a/wikimedia.de/forms/d/e/1FAIpQLScyzOcB9FmgWWrenoe0RnCyXo6F9YZyustrmsrD0g0zTRr2Cg/viewform
[4] Overview of organized groups’ discussions
https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2017/Outreach/List
[5] https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2017/Track_B
[6] 
https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2017/Toolkit/Discussion_guide
[7] 
https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2017/Process/Briefing
[8] https://meta.wikimedia.org/wiki/Wikimedia_Conference_2017

-- 
Nicole Ebber
Adviser International Relations
Movement Strategy Track Lead: Organized Groups

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.
V. Eingetragen im Vereinsregister des Amtsgerichts
Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig
anerkannt durch das Finanzamt für Körperschaften I Berlin,
Steuernummer 27/029/42207.

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

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Rogol Domedonfors]

Derk-Jan

On Wed, Mar 15, 2017 at 12:29 PM, you wrote:

> You mean like here: https://www.mediawiki.org/wiki/Roadmap ?
>

No, because that page is not a roadmap but a list of pages none of which is
a roadmap in the sense I stated.


> Where it is already posting it's annual and quarterly plans to as much
> detail as anyone is able to predict a roadmap ?
>

A roadmap in the sense I asked for does not need to be detailed.  It does
need to be clear and comprehensible.  We know that there are longer terms
technical plans and projects (around parsers, editors and Flow) than these
plans which all seem to send within the next few months.


> No one from community is discussing it (at least other than those already
> discussing it before). This 'community participation' is nice and all, but
> time and again has shown, that most of the community simply doesn't have
> time to participate in mundane stuff like this. Which is logical, it's like
> asking all volunteers in the hospital to participate in hospital
> governance. Most of them are there to help patients, not to discuss
> politics. Of course, those who want to participate in governance should
> have the chance to involve themselves, and usually they do, but that's not
> most people.
> Also the community is heavily detached from practicalities that influence
> the planning and implementation, often causing them to go off into tangents
> that are super time intensive and inefficient for both parties, and not
> creating any additional value.
>
> It would be much better if we acknowledged such problems, rather than
> insist that there is a solution that we haven't spotted yet in 15 years...
> And that's exactly where I hope this guidance is going to land. A reference
> where we can mutually formalise our expectations, limitations and
> aspirations.
>
> DJ
>
> On Wed, Mar 15, 2017 at 8:19 AM, Rogol Domedonfors 
> wrote:
>
> > A good way of avoiding clashes would be to publish the technical roadmap
> > showing where WMF expects to be taking its technical development over the
> > next five years or so, for the community to discuss and comment on  I
> have
> > yet to hear any reason why this can not or should not be done.
> >
> > "Rogol"
> >
> > On Wed, Mar 15, 2017 at 1:48 AM, Pine W  wrote:
> >
> > > Quim,
> > >
> > > Thanks for the comments.
> > >
> > > A brief note about the goal of "there are no clashes between product
> > > development teams and communities". That is an ambitious goal around
> > here,
> > > partly because there are changes planned and happening concurrently in
> so
> > > many places that I think it would be a challenge to surface all
> potential
> > > conflicts early and make them visible to relevant community members.
> (As
> > an
> > > example, a change that might be received favorably on Wiki A might
> > generate
> > > a commotion on Wiki B because it broke an existing tool, made an
> existing
> > > workflow take longer, or conflicts with their community's priorities. A
> > > current example of this kind of situation is with Flow, which the last
> I
> > > heard is viewed favorably on Catalan Wikipedia and unfavorably on
> English
> > > Wikipedia). I'm not sure that clashes can be 100% prevented, but I'm
> > > thinking that once the Newsletter extension is working, that might be a
> > > useful way of informing more interested people in a more timely fashion
> > > about planned changes, and encouraging people to enroll as beta testers
> > and
> > > translators, so that there are fewer surprises.
> > >
> > > I think that what might be a more readily solvable problem would be a
> > > standardized way of resolving clashes between product teams and
> > communities
> > > so that, when such clashes almost inevitably happen at some point,
> > > resolution comes sooner rather than later and hopefully in a way that
> is
> > > mutually acceptable. Perhaps that could be discussed in the Technical
> > > Collaboration Guidance document.
> > >
> > > Pine
> > > ___
> > > 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 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] Status of Technical Collaboration Guidance discussion

[Fæ]

A biennial planning process makes a lot of sense, so long as
transparency and accountability is not lost.

In the planning year, the most resource efficient way of doing this
stuff is to make strategy and operations 6 months out of phase,
ensuring that the management and executive don't exhaust themselves
with an impossible burden. Going a step further and designing a
biennial cycle, makes it possible to be more ambitious with a 24 month
horizon rather than just the financial 12 months, so the organization
can consider significant organizational changes to complete in that
time, and be more transparent about being measured. For example, if
something new is performing very badly in the first 3 months, the fact
that you have up to 21 more months to turn it around, or completely
reset, be creative, and still deliver against the measurable strategic
targets, is much more realistic.

So, good, I hope the WMF jumps over to this way of working, they
should be mature enough by now.

Fae

On 15 March 2017 at 17:46, Pine W  wrote:
> For what it's worth, my understanding is that WMF is considering
> transitioning portions of its annual planning to biannual planning.
>
> Also, I think that it will be easier to develop a long term technical
> roadmap after WMF completes its strategy update.
>
> Pine
>
>
> On Wed, Mar 15, 2017 at 12:19 AM, Rogol Domedonfors 
> wrote:
>
>> A good way of avoiding clashes would be to publish the technical roadmap
>> showing where WMF expects to be taking its technical development over the
>> next five years or so, for the community to discuss and comment on  I have
>> yet to hear any reason why this can not or should not be done.
>>
>> "Rogol"
>>
>> On Wed, Mar 15, 2017 at 1:48 AM, Pine W  wrote:
>>
>> > Quim,
>> >
>> > Thanks for the comments.
>> >
>> > A brief note about the goal of "there are no clashes between product
>> > development teams and communities". That is an ambitious goal around
>> here,
>> > partly because there are changes planned and happening concurrently in so
>> > many places that I think it would be a challenge to surface all potential
>> > conflicts early and make them visible to relevant community members. (As
>> an
>> > example, a change that might be received favorably on Wiki A might
>> generate
>> > a commotion on Wiki B because it broke an existing tool, made an existing
>> > workflow take longer, or conflicts with their community's priorities. A
>> > current example of this kind of situation is with Flow, which the last I
>> > heard is viewed favorably on Catalan Wikipedia and unfavorably on English
>> > Wikipedia). I'm not sure that clashes can be 100% prevented, but I'm
>> > thinking that once the Newsletter extension is working, that might be a
>> > useful way of informing more interested people in a more timely fashion
>> > about planned changes, and encouraging people to enroll as beta testers
>> and
>> > translators, so that there are fewer surprises.
>> >
>> > I think that what might be a more readily solvable problem would be a
>> > standardized way of resolving clashes between product teams and
>> communities
>> > so that, when such clashes almost inevitably happen at some point,
>> > resolution comes sooner rather than later and hopefully in a way that is
>> > mutually acceptable. Perhaps that could be discussed in the Technical
>> > Collaboration Guidance document.
>> >
>> > Pine
>> > ___
>> > 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 mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
fae...@gmail.com https://commons.wikimedia.org/wiki/User:Fae
Personal and confidential, please do not circulate or re-quote.

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

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Rogol Domedonfors]

Derk-Jan

On Wed, Mar 15, 2017 at 12:29 PM, you wrote:

> You mean like here: https://www.mediawiki.org/wiki/Roadmap ?
>

No, because that page is not a roadmap but a list of pages none of which is
a roadmap in the sense I stated, and I rather think you knew that when you
referrd to it.


> Where it is already posting it's annual and quarterly plans to as much
> detail as anyone is able to predict a roadmap ?
>

A roadmap in the sense I asked for does not need to be detailed.  It does
need to be clear and comprehensible.  It looks out further than the end of
the current work year.  We know that there are longer terms technical plans
and projects (around parsers, editors and Flow) than these plans which all
seem to send within the next few months.


> Of course, those who want to participate in governance should
> have the chance to involve themselves, and usually they do, but that's not
> most people.
>

I wish that were ture, but it has not been my experience.

It would be much better if we acknowledged such problems, rather than
> insist that there is a solution that we haven't spotted yet in 15 years...
> And that's exactly where I hope this guidance is going to land. A reference
> where we can mutually formalise our expectations, limitations and
> aspirations.
>

This is exactly what I'm arguing for.  But this guidance seems unlikely to
achieve it.

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

[Wikitech-l] 2017-03-15 Scrum of Scrums meeting notes

[Grace Gellerman]

https://www.mediawiki.org/wiki/Scrum_of_scrums/2017-03-15

= 2017-03-15=
contact: https://www.mediawiki.org/wiki/Wikimedia_Engineering

== Call outs ==
*  QUnit failures with Jenkins (ie https://phabricator.wikimedia.org/T153038
 ) is poping up time-to-time. Some more eyes are needed.
* DBAs asking for more eyes on
http://phabricator.wikimedia.org/T159319 (security
bug) clicking certain links 5 times brings down a 512GB mediawiki database
(either security, performance or mediawiki-core)


=== Technology ===

== Analytics ==
* Blocked on DBA chnages for eventlogging change, we wnat to have user
agent parsed on db but length is over column limit and it gets truncated:
https://phabricator.wikimedia.org/T160454


   - Finished cluster upgrade to new cloudera, no major disruptions to
   existing jobs but we had to modify our most complicated jobs, the edit
   reconstruction



   - Many tweaks to piwik (system we use to count pageviews to things such
   us annual report) so it can sustain usage, we had to ask iOS team to lower
   request count.



   - Prototype for new wikistats 2.0 frontend on the works, using vue.js,
   just storyboard for now, no real data:
   *https://analytics-prototype.wmflabs.org/#/*
   



   - People are using* event streams*  data to build cool things, blogpost
   on the way:*https://sachaysl.github.io/wikimedia-challenge/*
   



== Product ==
=== Reading ===
Web
* Last week:
** This sprint:
https://phabricator.wikimedia.org/tag/reading-web-sprint-93-%F0%9F%94%8D%F0%9F%94%8D%F0%9F%94%8D%F0%9F%94%8D%F0%9F%94%8D/
** PagePreviews instrumentation for monitoring performance via statsv.
** Fixed PagePreviews IE quirks and other non-IE issues.
* Next week:
** Next sprint: https://phabricator.wikimedia.org/project/view/2622/
** Upgrade MF browser tests to work with the new version of Selenium.
** PagePreviews instrumentation and other bugfixes
** Print styles

Android
* Last week:
** Many UI enhancements for better offline support, especially to reading
lists
** New saved page cache implementation still in progress T156917
** Continuous integration Android SDK upgrade debugging (with releng
support!)
** Started using kanban release boards officially
* Next week (https://phabricator.wikimedia.org/project/view/2352/ ):
** Continue improving the offline experience
** Start 2.5.x release https://phabricator.wikimedia.org/project/board/2667/

 iOS 
* Last Week
** 5.4 https://phabricator.wikimedia.org/project/view/2326/
*** Bux fixes and polish on Places
*** Continued work on login and 2FA (two-factor authentication)
* This week
** Continue work on 5.4
*** Places updates for iPad
*** JS consolidation w/ Android
*** Final bug fixes for release early next week

Reading Infrastructure
* deploying PageViewInfo this week https://phabricator.wikimedia.org/T125917
* TemplateStyles:
** trying to wrap up TemplateStyles RfC, could use more feedback:
https://phabricator.wikimedia.org/T155813
** https://gerrit.wikimedia.org/r/#/q/project:css-sanitizer
(MediaWiki-independent
CSS parser/sanitizer library) could use reviews
* ORES:
** https://gerrit.wikimedia.org/r/#/c/336963/ (hooks + data attributes for
change list items) could use reviews
* MCS: https://phabricator.wikimedia.org/project/view/2445/
** Bug fixes for T159252 (syntax error) and T159860 (reflinks with : in
title)
** More languages for TFA


Community Tech
* XTools rewrite going well, working Articleinfo and Top edits
http://tools.wmflabs.org/xtools-dev/articleinfo
* Improving LoginNotify https://phabricator.wikimedia.org/T160031
* More Popular Pages bot improvements
https://phabricator.wikimedia.org/T159774
https://phabricator.wikimedia.org/T160201
* Still working on cookie blocks (very difficult to test)
https://phabricator.wikimedia.org/T152952
* Range Contributions scrapped from CommTech sprint, now a 10% / volunteer
project https://phabricator.wikimedia.org/T145912

=== Editing ===
 UI Standardization 
* This week
** Bringing WikimediaUI Base Less variable file to core
** Some additions to the style guide, both technical and content-wise
https://phabricator.wikimedia.org/tag/wikimediaui_style_guide/
** mediawiki.UI checkboxes and radios in alignment with OOjs UI
* Updates
** OOjs UI:
*** Release of v0.20.0
 Huge improvement on/resolving almost entirely `em` sizing based
interface issues across browsers
 Also including 11 UI touching patches (icon deprecations, removed icon
flags, color amendments, vertical rhythm)
https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/History.md

 Parsing 
[[ Subbu won't be around .. but update posted here ]]

* Visual diff testing and bug fixing of RemexHTML use in core as a Tidy
replacement almost complete. We are in the process of figuring out rollout
of ParserMigration extension for editors to experiment with this
replacement. Tidy will be 

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Pine W]

For what it's worth, my understanding is that WMF is considering
transitioning portions of its annual planning to biannual planning.

Also, I think that it will be easier to develop a long term technical
roadmap after WMF completes its strategy update.

Pine


On Wed, Mar 15, 2017 at 12:19 AM, Rogol Domedonfors 
wrote:

> A good way of avoiding clashes would be to publish the technical roadmap
> showing where WMF expects to be taking its technical development over the
> next five years or so, for the community to discuss and comment on  I have
> yet to hear any reason why this can not or should not be done.
>
> "Rogol"
>
> On Wed, Mar 15, 2017 at 1:48 AM, Pine W  wrote:
>
> > Quim,
> >
> > Thanks for the comments.
> >
> > A brief note about the goal of "there are no clashes between product
> > development teams and communities". That is an ambitious goal around
> here,
> > partly because there are changes planned and happening concurrently in so
> > many places that I think it would be a challenge to surface all potential
> > conflicts early and make them visible to relevant community members. (As
> an
> > example, a change that might be received favorably on Wiki A might
> generate
> > a commotion on Wiki B because it broke an existing tool, made an existing
> > workflow take longer, or conflicts with their community's priorities. A
> > current example of this kind of situation is with Flow, which the last I
> > heard is viewed favorably on Catalan Wikipedia and unfavorably on English
> > Wikipedia). I'm not sure that clashes can be 100% prevented, but I'm
> > thinking that once the Newsletter extension is working, that might be a
> > useful way of informing more interested people in a more timely fashion
> > about planned changes, and encouraging people to enroll as beta testers
> and
> > translators, so that there are fewer surprises.
> >
> > I think that what might be a more readily solvable problem would be a
> > standardized way of resolving clashes between product teams and
> communities
> > so that, when such clashes almost inevitably happen at some point,
> > resolution comes sooner rather than later and hopefully in a way that is
> > mutually acceptable. Perhaps that could be discussed in the Technical
> > Collaboration Guidance document.
> >
> > Pine
> > ___
> > 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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Fwd: [Wikimedia-l] Product draft goals posted on mediawiki

[Pine W]

Forwarding.

Pine


-- Forwarded message --
From: Toby Negrin 
Date: Wed, Mar 15, 2017 at 7:50 AM
Subject: [Wikimedia-l] Product draft goals posted on mediawiki
To: Wikimedia Mailing List 


Hi everyone --

I wanted to let you know that the product team has posted our draft goals
for next quarter (the fourth quarter of the Foundation's fiscal year aka
Q4) up on mediawiki:

https://www.mediawiki.org/wiki/Wikimedia_Engineering/
2016-17_Q4_Goals#Product

Please take a look and let us know your thoughts on the talk page. We'd
like to lock these goals and make a commitment to them in a week or two.

thanks,

-Toby
___
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/
wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/
wiki/Wikimedia-l
New messages to: wikimedi...@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,

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

[Wikitech-l] GSOC'17/Outreachy'14: Mentor needed for software design and code review guidance

[Srishti Sethi]

There are a few prospective students interested in working on the Single
Image Batch Upload  project.

We've recruited two mentors already @basvb and @capt_swing (on
Phabricator), but we still need a mentor who could provide software design
guidance and help with the code review process. See comments here:
https://phabricator.wikimedia.org/T138464#3098154

Anyone willing to offer help?

Thank you!!

-- 
Srishti Sethi
Developer Advocate
Technical Collaboration team
Wikimedia Foundation

https://www.mediawiki.org/wiki/User:SSethi_(WMF)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Derk-Jan Hartman]

You mean like here: https://www.mediawiki.org/wiki/Roadmap ?

Where it is already posting it's annual and quarterly plans to as much
detail as anyone is able to predict a roadmap ?

No one from community is discussing it (at least other than those already
discussing it before). This 'community participation' is nice and all, but
time and again has shown, that most of the community simply doesn't have
time to participate in mundane stuff like this. Which is logical, it's like
asking all volunteers in the hospital to participate in hospital
governance. Most of them are there to help patients, not to discuss
politics. Of course, those who want to participate in governance should
have the chance to involve themselves, and usually they do, but that's not
most people.
Also the community is heavily detached from practicalities that influence
the planning and implementation, often causing them to go off into tangents
that are super time intensive and inefficient for both parties, and not
creating any additional value.

It would be much better if we acknowledged such problems, rather than
insist that there is a solution that we haven't spotted yet in 15 years...
And that's exactly where I hope this guidance is going to land. A reference
where we can mutually formalise our expectations, limitations and
aspirations.

DJ

On Wed, Mar 15, 2017 at 8:19 AM, Rogol Domedonfors 
wrote:

> A good way of avoiding clashes would be to publish the technical roadmap
> showing where WMF expects to be taking its technical development over the
> next five years or so, for the community to discuss and comment on  I have
> yet to hear any reason why this can not or should not be done.
>
> "Rogol"
>
> On Wed, Mar 15, 2017 at 1:48 AM, Pine W  wrote:
>
> > Quim,
> >
> > Thanks for the comments.
> >
> > A brief note about the goal of "there are no clashes between product
> > development teams and communities". That is an ambitious goal around
> here,
> > partly because there are changes planned and happening concurrently in so
> > many places that I think it would be a challenge to surface all potential
> > conflicts early and make them visible to relevant community members. (As
> an
> > example, a change that might be received favorably on Wiki A might
> generate
> > a commotion on Wiki B because it broke an existing tool, made an existing
> > workflow take longer, or conflicts with their community's priorities. A
> > current example of this kind of situation is with Flow, which the last I
> > heard is viewed favorably on Catalan Wikipedia and unfavorably on English
> > Wikipedia). I'm not sure that clashes can be 100% prevented, but I'm
> > thinking that once the Newsletter extension is working, that might be a
> > useful way of informing more interested people in a more timely fashion
> > about planned changes, and encouraging people to enroll as beta testers
> and
> > translators, so that there are fewer surprises.
> >
> > I think that what might be a more readily solvable problem would be a
> > standardized way of resolving clashes between product teams and
> communities
> > so that, when such clashes almost inevitably happen at some point,
> > resolution comes sooner rather than later and hopefully in a way that is
> > mutually acceptable. Perhaps that could be discussed in the Technical
> > Collaboration Guidance document.
> >
> > Pine
> > ___
> > 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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Status of Technical Collaboration Guidance discussion

[Rogol Domedonfors]

A good way of avoiding clashes would be to publish the technical roadmap
showing where WMF expects to be taking its technical development over the
next five years or so, for the community to discuss and comment on  I have
yet to hear any reason why this can not or should not be done.

"Rogol"

On Wed, Mar 15, 2017 at 1:48 AM, Pine W  wrote:

> Quim,
>
> Thanks for the comments.
>
> A brief note about the goal of "there are no clashes between product
> development teams and communities". That is an ambitious goal around here,
> partly because there are changes planned and happening concurrently in so
> many places that I think it would be a challenge to surface all potential
> conflicts early and make them visible to relevant community members. (As an
> example, a change that might be received favorably on Wiki A might generate
> a commotion on Wiki B because it broke an existing tool, made an existing
> workflow take longer, or conflicts with their community's priorities. A
> current example of this kind of situation is with Flow, which the last I
> heard is viewed favorably on Catalan Wikipedia and unfavorably on English
> Wikipedia). I'm not sure that clashes can be 100% prevented, but I'm
> thinking that once the Newsletter extension is working, that might be a
> useful way of informing more interested people in a more timely fashion
> about planned changes, and encouraging people to enroll as beta testers and
> translators, so that there are fewer surprises.
>
> I think that what might be a more readily solvable problem would be a
> standardized way of resolving clashes between product teams and communities
> so that, when such clashes almost inevitably happen at some point,
> resolution comes sooner rather than later and hopefully in a way that is
> mutually acceptable. Perhaps that could be discussed in the Technical
> Collaboration Guidance document.
>
> Pine
> ___
> 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