Re: [Wikitech-l] Yandex?

[Federico Leva (Nemo)]

FYI https://meta.wikimedia.org/wiki/Wikimedia_projects has a list; it 
means the wikis themselves (MediaWiki), not stuff around them.


Nemo

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

Re: [Wikitech-l] Yandex?

[Ricordisamoa]

Il 02/07/2015 21:55, Legoktm ha scritto:

I am also interested in the answer to Nemo's question about whether this
"is the first piece of proprietary software ever entering use in the
Wikimedia projects land?"


Also Qualtrics 





-- Legoktm

___
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] Yandex?

[Gergő Tisza]

On Thu, Jul 2, 2015 at 12:55 PM, Legoktm 
wrote:

> I am also interested in the answer to Nemo's question about whether this
> "is the first piece of proprietary software ever entering use in the
> Wikimedia projects land?"
>

Translatewiki has been using Yandex for a while (and used Google while it
was available, and a third one I can't remember right now).
Not sure if it counts as a Wikimedia project or not.

We also use MaxMind for geolocation, which is I believe free software using
a proprietary database.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] The end of the Roadmap Phabricator project

[Gergo Tisza]

On Thu, Jul 2, 2015 at 4:17 PM, Greg Grossmeier  wrote:

> Let me know if you have any concerns,


I don't think all (or even the main) use cases of #roadmap are covered by
the proposal.

* #user-notice is much more noisy. A #roadmap task is "describing a
significant new piece of user-facing functionality or the launch of a new
API or service", while #user-notice should be put on any small bugfix that
might affect somebody's workflow.[1] It also does not have any time
component; #user-notice is typically put on some task so that a newsletter
entry can be made when the task is closed. There is no telling beforehand
when that will happen. It has proven a great mechanism for making sure that
users learn of change right before it happens. It is not useful at all for
getting a high-level overview of what's going to happen (i.e. a roadmap).
* the deployment calendar is completely useless for non-developers. (For
developers, it's just mostly useless, and time-consuming to use.) It also
only shows the next 1-2 weeks .
* #release is used by products which have a version number, which the
majority of Wikimedia software does not. And they don't have a time
component either. (In general the tag seems fairly useless to me.)

The main use case for #roadmap, as I understand it, is to keep track of
work towards quarterly goals. Erik's original proposal for the roadmap tag
said: "this could ultimately replace some of the detail in the on-wiki
goals pages, and ensure we have a single calendar type view into expected
deliverables". None of the proposed replacements comes even close to
fulfilling that role.


[1] which, as we know, is a rather low bar. https://xkcd.com/1172/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Upcoming in October: Seattle GNU/Linux conference

[Pine W]

The 2015 Seattle GNU/Linux conference (SeaGL) call for proposals is now
open. I've submitted a proposal for a 50-minute workshop regarding how to
edit Wikipedia, and may submit more proposals in collaboration with my
colleagues in Cascadia Wikimedians. I'm sure that SeaGL would be happy to
consider technical presentations about MediaWiki, Wikimedia analytics,
Wikimedia Labs, our upstream tools, etc. if you're interested. Please
consider submitting a proposal and coming to Seattle for the conference.

http://seagl.org/

Regards,

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

Re: [Wikitech-l] Yandex?

[Dan Garry]

On 2 July 2015 at 12:55, Legoktm  wrote:

> I am also interested in the answer to Nemo's question about whether this
> "is the first piece of proprietary software ever entering use in the
> Wikimedia projects land?"
>

The iOS app uses system libraries provided by the iOS SDK for a variety of
essential functions, and obviously both the devices and the technology
stack are proprietary. That's just the price we pay for wanting to be part
of that ecosystem. The app and all the non-system third party libraries it
uses (i.e. anything we reasonably have control over) are open source.

The Android app is the same as the iOS app, except the Android operating
system is open source and published under the Apache licence. That said,
Android devices typically ship with proprietary software installed on them
which the app does use, such as Google Play which is used for delivery of
the application to most users.

Dan

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

[Wikitech-l] The end of the Roadmap Phabricator project

[Greg Grossmeier]

Hello all,

First, some history and context:

The #roadmap project[0] in our Phabricator instance was set up by Erik M
as a trial way of tracking upcoming releases, deployments, and generally
"new things of note", as these previously weren't tracked in one place.
It has a workboard[1] that is is broken up into:
* one column for each week for the current month
* one column for each remaining month in the current quarter
* then "not soon"

The scope of this project covered both "things that might break the site
or are otherwise risky" and also "things people might expect to be
notified about". At the time things got released quite often without a
standard way for people to find that they were coming.

I helped Erik with maintaining this project because it was also useful
for our weekly "roadmap and deployments update" meeting where most WMF
engineering managers got together for about 15-30 minutes to go over:
* What, of note, is going out next week?
* What, of note, is going out in the near term (i.e.: next few weeks)?
* Anything else we should know about?

Outcomes of this meeting were:
* An updated outline of upcoming deployments on the Deployment
  Calendar[2]
** This helped inform the work of the WMF RelEng and Ops teams,
   especially
* A time/space for people (especially Erik or others with intimate
  "community knowledge/intuition") to object to something going out at
  all, or at the proposed time


Since this project was set up, Guillaume started the #user-notice and
#developer-notice projects [4][5], which cover the "things to tell
people about" a lot better, are much more general covering incidents and
planned outages as well as code deployments, and are communicated out
via volunteer translators to dozens of community notice boards every
week.


== Current world / Assessment ==

We are still using the #roadmap project for a lot of things that don't
risk deployment/stability disruption, and also updating the Deployments
Calendar on wikitech. It is my opinion that there is not enough gain
from maintaining both work products to justify the effort, especially as
#user-notice and #developer-notice have become so valuable.


== Proposal ==

I propose that we discontinue the use of #roadmap.

Potential gaps created by the deprecating of #roadmap and my proposed
solutions:

* Lack of a project that tracks big upcoming software/product releases
**  The #release[3] project was created for this

* Lack of a time-scale perspective of upcoming releases/deployments
** I believe that the Deployments Calendar[2], while imperfect (wiki
   templates), fulfills this

* Users aren't informed of upcoming changes
** the #user-notice[4] project in Phabricator should be used for that


== Expectations ==

To successfully do this (deprecate #roadmap) I expect all WMF
Engineering teams (as the group of developers I have more influence over
versus the Wikimedia engineering community) to pro-actively communicate
out their plans, in public, with the appropriate use of the Deployments
Calendar and the #user-notice Phabricator project. This means engaging
with the Community Engagement/Liaison team when appropriate.

In no small way this is me, as Release Manager, showing trust in the
work of the WMF Engineering teams (which includes the product managers).
Do good things with it :-)

Let me know if you have any concerns,

Greg


[0] https://phabricator.wikimedia.org/project/profile/1109/
[1] https://phabricator.wikimedia.org/project/board/1109/
[2] https://wikitech.wikimedia.org/wiki/Deployments
[3] https://phabricator.wikimedia.org/project/profile/1333/
[4] https://phabricator.wikimedia.org/tag/user-notice/
[5] https://phabricator.wikimedia.org/tag/developer-notice/

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


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

Re: [Wikitech-l] Yandex?

[David Gerard]

On 2 July 2015 at 20:55, Legoktm  wrote:

> I am also interested in the answer to Nemo's question about whether this
> "is the first piece of proprietary software ever entering use in the
> Wikimedia projects land?"


[not actually relevant, but since you ask ...]

First would have been Java, back when that was non-free - with Lucene
running on it as a search engine. Then someone ported Lucene to C# so
we used that version on Mono (an all-free stack in copyright terms at
least), then Sun promised to free Java so we adopted Java before it
was actually free but while the process was underway. I recall Sun
also donated some Solaris 10 SPARC boxes which were used for various
non-core purposes. This is all off the top of my head and I welcome
historical correction.


- d.

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

Re: [Wikitech-l] Yandex?

[Jackmcbarn]

On Thu, Jul 2, 2015 at 3:55 PM, Legoktm  wrote:

> So it appears that ContentTranslation will be contacting a third-party,
> closed source service? Are users going to be informed that this is the
> case? What data is being sent?
>
> I am also interested in the answer to Nemo's question about whether this
> "is the first piece of proprietary software ever entering use in the
> Wikimedia projects land?"
>
All of those questions concern me. I'm 100% against any sort of integration
with any proprietary software or service. This really needs more notice and
wider discussion.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Yandex?

[Legoktm]

On 07/01/2015 06:50 PM, Ricordisamoa wrote:
> Il 02/07/2015 03:28, Legoktm ha scritto:
>> I noticed: "Yandex coming up soon!" under ContentTranslation. Are there
>> more details about what this means?
> 
> https://phabricator.wikimedia.org/T89844 I think

Thanks for the pointer. After some more digging, I found
.

So it appears that ContentTranslation will be contacting a third-party,
closed source service? Are users going to be informed that this is the
case? What data is being sent?

I am also interested in the answer to Nemo's question about whether this
"is the first piece of proprietary software ever entering use in the
Wikimedia projects land?"

-- Legoktm

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

Re: [Wikitech-l] Data and Developer Hub protoype

[Isarra Yos]

On 26/06/15 21:21, Quim Gil wrote:

Note that probably the complementary side of your frustration is the
frustration of designers and others trying to improve Wikimedia and its
projects, only to find a strong resistance to change almost every time that
fresh ideas are proposed. In our case here, currently we are not very
successful at attracting third party developers to use our APIs, definitely
not at the scale that one would expect considering Wikipedia's relevance.
We welcome ideas and help from people willing to solve this problem. We are
happy to take risks trying solutions, even if that means that we will make
some mistakes along the way.


It should perhaps be noted that this seems a continuation on a general 
trend to avoid learning how to work with the communities and existing 
designs. It may be faster and less frustrating to simply sod off and do 
something new somewhere else, but this does not solve the existing 
problems - all it does is introduce more inconsistencies and more things 
that need to be consolidated later, if they survive at all. Except they 
usually don't, because ignoring what people do and use and expect does 
not lead to practical designs, it leads to things people don't use, 
maintain, or contribute to, which brings us back in part to the 
technical debt associated with having so many different wikis.


But when it comes to working with what already exists, I know from 
experience that this is far from easy, and in fact often incredibly 
frustrating in practice. Thing is, though, we have to - the existing 
products need to be worked with in order to move forward. That's just 
how it is.


As we tend to say about the unsolicited redesigns of (en) wikipedia, 
it's always a lot easier when you don't have to design with reality as a 
constraint. There's a reason we never use any of them.


-I

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

[Wikitech-l] Failed jobs will never run again

[Henning Vreyborg]

Hi there,

it seems that failed  jobs will never be executed again.

My extension creates jobs that talk with an external server via soap. 
This connection might fail (e.g. server maintenance) which then means 
that my job fails and needs to be reexecuted later.
On my wiki I am running $wgJobRunRate = 0, my extension job is in 
$wgJobTypesExcludedFromDefaultQueue. To run my jobs I have a cronjob 
with "php runJobs.php --maxjobs 10 --type CreateTicket". My job has 
allowRetries() implemented with "return true".


From my observations the "job_token" and "job_token_timestamp" fields 
in the job table are used as a LOCK so that no job gets executed twice. 
The only problem is that these fields are never emptied, if the job 
fails (return false), so that the job scheduler can reexecute them.


Is this intended behaviour or is this a bug? Does anyone have an idea 
how to solve this issue?


Thank you.
Regards
Henning Vreyborg
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l