Re: [Wikitech-l] CONFLICT (content): Merge conflict in RELEASE-NOTES-1.23

[Antoine Musso]

Le 05/11/13 21:45, Ori Livneh a écrit :
> If this drives you barking mad too, fix it. Should be doable by
> injecting a bit of code here:
> 
> http://git.wikimedia.org/blob/integration%2Fzuul.git/ac3ba4fe9f9dace5673a6537ef0d3ccf5a054ac7/zuul%2Fmerger.py#L71
> 
> I will personally build a statue in your honor

We could surely add a feature in Zuul that would let us ignore conflicts
for some files.  That should be possible by defining a merge driver
using the "ours" strategy and then apply that driver in /.gitattributes
for the RELEASE-NOTES* files.

A side effect is that the gate-and-submit jobs would work properly but
Gerrit would end up refusing to submit the patchset because it cant
merge it :-/

So that would merely delay the conflict resolution to post +2 which is
even more annoying.

-- 
Antoine "hashar" Musso


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

Re: [Wikitech-l] CONFLICT (content): Merge conflict in RELEASE-NOTES-1.23

[Bartosz Dziewoński]

On Wed, 06 Nov 2013 09:40:59 +0100, Antoine Musso  wrote:


We could surely add a feature in Zuul that would let us ignore conflicts
for some files.  That should be possible by defining a merge driver
using the "ours" strategy and then apply that driver in /.gitattributes
for the RELEASE-NOTES* files.


You could probably use my driver for this (linked in earlier post, also [1]), 
which does some mostly meaningful checks to decide if the release notes are 
mergeable.



A side effect is that the gate-and-submit jobs would work properly but
Gerrit would end up refusing to submit the patchset because it cant
merge it :-/


Yeah… JGit (which is what gerrit uses instead of git) does also supports merge 
drivers (or so says its documentation), it can't possibly be very hard to set 
one up – someone would just have to reimplement the algorithm in Java.

Or maybe we could have another bot to rebase using my driver before 
gate-and-submit runs. But personally I have no idea if/how it could be 
implemented; Antoine?


[1] https://github.com/MatmaRex/mediawikireleasenotes-driver

--
Matma Rex

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

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Steven Walling]

On Tue, Nov 5, 2013 at 9:06 PM, Nathan Larson wrote:

> > (snip)
> > I actually like the formalism a bit - since it at least makes sure
> > that they don't rot. BDFLs are good.
> >
> >
> Does it keep them from rotting? It looks like of the 60 RFCs in draft or in
> discussion, 24 were last updated before 2013.
>
> https://www.mediawiki.org/wiki/User:Leucosticte/RFCs_sorted_by_%22updated%22_date
>

Weren't most of the RFCs you're talking about started before the new
process was implemented? There's a lot of cleanup work to be done, and so
far it seems like decent progress has been made. I agree we could be more
aggressive about closing RFCs that are long stale, but it's hard to fault
an architectural process that replaces what amounted to a vacuum. It's not
like RFCs were all tidy and making progress before any new process was
announced.

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

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Ori Livneh]

On Tue, Nov 5, 2013 at 5:57 PM, Erik Moeller  wrote:
> tl;dr: I’d appreciate thoughts from the Wikimedia technical community
> at large whether the designation of individual technical contributors
> as "architects" should be meaningful, and if so, how to expand it
> beyond the original triumvirate (Brion, Tim & Mark), e.g. by
> transitioning to a community-driven process for recognizing
> architects.
>
> Hi all,
>
> in March 2011 and June 2011, Brion Vibber, Mark Bergsma and Tim
> Starling were announced as Lead Software Architect, Lead Operations
> Architect and Lead Platform Architect of the Wikimedia Foundation,
> respectively. Together, these three individuals laid much of the
> foundation of Wikimedia’s technical infrastructure, from MediaWiki
> itself to our caching and load balancing setup. So it was a logical
> step to recognize their immense contributions, and to entrust them
> with continued high-level stewardship in Wikimedia’s technical
> ecosystem.
>
> Since then, WMF's engineering organization has grown pretty
> dramatically. We've also seen increased engagement in the Wikimedia
> technical community from other organizations. Wikimedia Germany is
> probably most notable among them with the Wikidata project, and Wikia
> has partnered directly on VisualEditor development and is generally
> striving to increase visibility of its open source modifications to
> MediaWiki.
>
> At WMF, this has increasingly raised the question how the architecture
> of Wikimedia’s technical infrastructure can be evolved at this new,
> larger scale, and how we can bring more voices into that conversation.
> I've shared this note with the architects ahead of time and taken some
> initial feedback into account.
>
> Rob Lanphier has taken a lead role in giving the RFC process a kick in
> the pants as a solid, asynchronous, transparent process for organizing
> and resolving technical proposals. Brion, Tim and Mark are explicitly
> listed as the three individuals who can close an RFC (interpreting or
> helping reach consensus, or making an informed decision where there’s
> a lack of community participation), and have helped clear the RFC
> backlog and evolve the architecture guidelines. In addition, Rob is
> organizing the MediaWiki architecture summit in January, where we can
> talk about some of the most pressing or contentious architectural
> questions in person.
>
> However, Brion, Tim and Mark are not infinitely scalable, nor are they
> immortal (except in our hearts). They can’t be in every conversation,
> know every part of Wikimedia’s technical ecosystem, review every RFC,
> etc. We also have many other deeply talented technical contributors,
> including some who have many years of experience in our technical
> context specifically -- not just at WMF. Beyond just making technical
> decisions, architectural leadership creates opportunities for
> mentorship, modeling and nurturing the kind of behavior we want to
> foster in our technical community.
>
> So how should this role evolve going forward? Some possible paths (you
> know I like to present options ;-):
>
> Option A: We change nothing and don't promote any new people into
> architect roles for a while. I truly don’t think this is an option for
> much longer -- we need to find better ways to encourage some of our
> other capable technical contributors to feel ownership over
> Wikimedia’s technical direction, and fill gaps in architectural
> leadership today. That said, it would be possible to make the RFC
> process more egalitarian and to reduce the emphasis on formalized
> technical leadership.
>
> Option B: WMF handles it as it sees fit. This basically means WMF gets
> to decide who to designate as "Architects" and at what point, which
> would mostly leave this decision in the hands of managers. This is a
> very WMF-centric view of the world, but it’s of course the way most
> organizations operate.
>
> Option C: We get rid of the special role of architects. I personally
> don’t favor this option either, because I think recognizing the most
> sane and experienced voices in our technical community and according
> them some real leadership influence over Wikimedia’s technical
> direction is important (and a useful counterbalance to pointy-haired
> folks like yours truly ;-).
>
> Option D: We come up with some kind of open process for
> designating/confirming folks as architects, according to some
> well-defined criteria (including minimum participation in the RFC
> process, well-defined domain expertise in certain areas, a track
> record of constructive engagement, etc.). Organizations like WMF can
> choose to recognize this role as they see fit (likely according salary
> increases to individuals who demonstrate successful architectural
> leadership), but it’s a technical leadership role that’s awarded by
> Wikimedia’s larger technical community, similar to +2 status.
>
> Each of these would need to be unpacked and further developed. For
> option D in particular

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Dan Garry]

Thinking about this, I am somewhat afraid that any public voting process
may become more similar to Requests for Bureaucratship (RfB).

For those not familiar with this process, it's an even more brutal thing
than RfA (Requests for Adminship). Bureaucrats are socially the people that
close the RfAs, and technically the only people with the ability to
actually make someone an administrator. The typical support required to
pass RfB is 90%, as opposed to the 70-75% [1] of RfA. For a while the RfB
process was considered impossible to pass, which led people to relax their
requirements of the candidates, and in turn led to the process being
passable again! An interesting feedback loop for regulation of the process.

The thing is, everyone on the English Wikipedia agrees that RfA sucks.
Everyone just thinks it sucks for different reasons, so nobody can agree on
a better process. I don't want to see this happen to any process that we
come with.

Dan

[1]: There are exceptions to this, and people have passed with lower
percentages. Chad on this list is one such exception.


On 6 November 2013 01:57, Erik Moeller  wrote:

> tl;dr: I’d appreciate thoughts from the Wikimedia technical community
> at large whether the designation of individual technical contributors
> as "architects" should be meaningful, and if so, how to expand it
> beyond the original triumvirate (Brion, Tim & Mark), e.g. by
> transitioning to a community-driven process for recognizing
> architects.
>
> Hi all,
>
> in March 2011 and June 2011, Brion Vibber, Mark Bergsma and Tim
> Starling were announced as Lead Software Architect, Lead Operations
> Architect and Lead Platform Architect of the Wikimedia Foundation,
> respectively. Together, these three individuals laid much of the
> foundation of Wikimedia’s technical infrastructure, from MediaWiki
> itself to our caching and load balancing setup. So it was a logical
> step to recognize their immense contributions, and to entrust them
> with continued high-level stewardship in Wikimedia’s technical
> ecosystem.
>
> Since then, WMF's engineering organization has grown pretty
> dramatically. We've also seen increased engagement in the Wikimedia
> technical community from other organizations. Wikimedia Germany is
> probably most notable among them with the Wikidata project, and Wikia
> has partnered directly on VisualEditor development and is generally
> striving to increase visibility of its open source modifications to
> MediaWiki.
>
> At WMF, this has increasingly raised the question how the architecture
> of Wikimedia’s technical infrastructure can be evolved at this new,
> larger scale, and how we can bring more voices into that conversation.
> I've shared this note with the architects ahead of time and taken some
> initial feedback into account.
>
> Rob Lanphier has taken a lead role in giving the RFC process a kick in
> the pants as a solid, asynchronous, transparent process for organizing
> and resolving technical proposals. Brion, Tim and Mark are explicitly
> listed as the three individuals who can close an RFC (interpreting or
> helping reach consensus, or making an informed decision where there’s
> a lack of community participation), and have helped clear the RFC
> backlog and evolve the architecture guidelines. In addition, Rob is
> organizing the MediaWiki architecture summit in January, where we can
> talk about some of the most pressing or contentious architectural
> questions in person.
>
> However, Brion, Tim and Mark are not infinitely scalable, nor are they
> immortal (except in our hearts). They can’t be in every conversation,
> know every part of Wikimedia’s technical ecosystem, review every RFC,
> etc. We also have many other deeply talented technical contributors,
> including some who have many years of experience in our technical
> context specifically -- not just at WMF. Beyond just making technical
> decisions, architectural leadership creates opportunities for
> mentorship, modeling and nurturing the kind of behavior we want to
> foster in our technical community.
>
> So how should this role evolve going forward? Some possible paths (you
> know I like to present options ;-):
>
> Option A: We change nothing and don't promote any new people into
> architect roles for a while. I truly don’t think this is an option for
> much longer -- we need to find better ways to encourage some of our
> other capable technical contributors to feel ownership over
> Wikimedia’s technical direction, and fill gaps in architectural
> leadership today. That said, it would be possible to make the RFC
> process more egalitarian and to reduce the emphasis on formalized
> technical leadership.
>
> Option B: WMF handles it as it sees fit. This basically means WMF gets
> to decide who to designate as "Architects" and at what point, which
> would mostly leave this decision in the hands of managers. This is a
> very WMF-centric view of the world, but it’s of course the way most
> organizations operate.
>
> 

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Antoine Musso]

Le 06/11/13 02:57, Erik Moeller a écrit :
> tl;dr: I’d appreciate thoughts from the Wikimedia technical community
> at large whether the designation of individual technical contributors
> as "architects" should be meaningful, and if so, how to expand it
> beyond the original triumvirate (Brion, Tim & Mark), e.g. by
> transitioning to a community-driven process for recognizing
> architects.


Hello,

I would have a look at the way IETF is handling its RFC process. I wrote
about it back in July in the thread "proposed RFC process":

 http://lists.wikimedia.org/pipermail/wikitech-l/2013-July/070241.html

The workflow is as bureaucratic as you can imagine given the number of
parties involved and all the political / commercial context that goes
behind creating internet standards. You can still achieve a RFC pretty
"quickly".


To scale out the architects roles, I would formalize the concept of self
organized working groups.  Their responsibility would be to produce a
draft to be presented to a technical board.  Once the standard is
approved / implemented / released, the working group is disbanded.


How would it work?

Any individual having an idea would expose it on wikitech-l to gain
people to its cause.  They would form a self organized working group
using whatever tools and practices they agree upon.  The aim of the
group would be to produce a draft.

The technical board would be made of the smartest people we have,
ideally including non wikimedia people.  To name a few, at the *very
minimum* I would include Brion, Tim, Mark and Ori and definitely Daniel
Kinzler from WMDE, probably adding Rob as the facilitator.


The board responsibilities would be:
- provide support to the working group leaders
- ensure working groups are progressing
- handle conflicts between members of a group
- ensure the working groups work are not overlapping
- accept the produced drafts as RFC.


Whenever a working group publishes a draft, it would be reviewed by
whoever is interested and amended until it has consensus.  The draft is
then proposed to the technical board which has the final word and
publish the draft as a RFC.


As to who is going to implement the RFC, I guess it depends on who needs
it in the first place.  Most of the time it would be for Wikimedia, so
the Wikimedia engineering managers would be responsible to get the
standard implemented, released and deployed.  The draft could well
propose a working implementation as well.


If a working group is working on an ambitious feature, it could probably
use some real life meeting from time to time.

The technical board could use some monthly meetings much like the RFC
review IRC meeting we are already having.


Finally, the MediaWiki architecture summit would gather all the working
groups members and technical board members with an agenda of drafts to
approve or vision of the next working groups to form.


Example:

https://www.mediawiki.org/wiki/Requests_for_comment/LESS

Working group was Ori Livneh, Jon Robson, Steven Walling. They came with
a draft and implementation after a few review cycles.

Along the process Brion stepped in to offer technical reviews/guidance.

Brion eventually accepted it by marking the RfC complete and merging the
implementation.

End result: MediaWiki now supports LESS.


My
ERROR: rounding error in '%s cents' % 0,02

-- 
Antoine "hashar" Musso


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

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Jeroen De Dauw]

Hey,

Some thoughts, in no particular order:

* Titles do not reflect ability, they reflect how titles are assigned in an
organization
* Some people see titles such as "software architect" as a stamp of
superiority
* Some people abuse their titles
* We would indeed be advised to keep the distinction between WMF and
MediaWiki in mind
* MediaWiki is not a shining beacon of good architecture. I'd argue it
should mostly be considered as a big blob of generally badly designed
legacy code
* Length of participation in a community, or the number of contributions,
does not linearly relate to ability
* Having a community process to decide who gets $fancyTitle, seems more
likely to result in the most popular people of the strongest subgroups to
get it then the most qualified ones. Same as what happens in politics.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] New Bugzilla users have restricted accounts

[MZMcBride]

Hi.

Our Bugzilla installation at  currently
restricts the capabilities of new users as a knee-jerk response to prior
Bugzilla-related vandalism. There are further details at
.

Increasingly new users are making manual requests to be assigned to bugs,
as they cannot edit others' bugs by default. This is problematic and
disruptive to development efforts.

My suggestion is to re-add the "editbugs" user right to new users by
default (revert the old settings adjustment). Otherwise, an acceptable
workaround needs to be found.

MZMcBride



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

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Chad]

On Wed, Nov 6, 2013 at 4:07 AM, Jeroen De Dauw wrote:

> * MediaWiki is not a shining beacon of good architecture. I'd argue it
> should mostly be considered as a big blob of generally badly designed
> legacy code
>

This has nothing to do with the subject at hand.

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

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Brion Vibber]

My brief thoughts:

* It makes sense to have a handful of folks as a core review & planning
group.

* However, I would consider avoiding using the term "Architect" for its
members as it's easily conflated with existing WMF job titles. I think job
titles are pretty unreliable indicators at the best of times, and of course
can be wildly inconsistent across companies.

* I've got no particular patience for over-formal community processes like
Wikipedia adminship voting, nor interest in replicating those processes.

While there are plenty of problems with the traditional FOSS concept of
"meritocracy", I still have great affection for the "do-it-ocracy" notion
that folks who actually get stuff done should be recognized as fulfilling
the roles they are performing.

As such, I'd recommend a slightly more formal role for additional "lead
reviewers" or "module owners" in the code review & RFC processes; not as
*gatekeepers* so much as to provide a next-step for getting something
moving that's stalled -- a potential contributor or a team within WMF
working on a feature should be able to easily determine who to talk to
about getting a go/no-go or advice on what to do in case of a no-go.

(For comparison, I occasionally write patches for Firefox and Firefox OS;
they have a *really full* bug tracker and your only hope of getting a patch
reviewed is to actually request review from a particular person. A list of
module owners like  is a
lifesaver for a casual contributor who doesn't know everybody on the
Mozilla teams.)

-- brion



On Tue, Nov 5, 2013 at 5:57 PM, Erik Moeller  wrote:

> tl;dr: I’d appreciate thoughts from the Wikimedia technical community
> at large whether the designation of individual technical contributors
> as "architects" should be meaningful, and if so, how to expand it
> beyond the original triumvirate (Brion, Tim & Mark), e.g. by
> transitioning to a community-driven process for recognizing
> architects.
>
> Hi all,
>
> in March 2011 and June 2011, Brion Vibber, Mark Bergsma and Tim
> Starling were announced as Lead Software Architect, Lead Operations
> Architect and Lead Platform Architect of the Wikimedia Foundation,
> respectively. Together, these three individuals laid much of the
> foundation of Wikimedia’s technical infrastructure, from MediaWiki
> itself to our caching and load balancing setup. So it was a logical
> step to recognize their immense contributions, and to entrust them
> with continued high-level stewardship in Wikimedia’s technical
> ecosystem.
>
> Since then, WMF's engineering organization has grown pretty
> dramatically. We've also seen increased engagement in the Wikimedia
> technical community from other organizations. Wikimedia Germany is
> probably most notable among them with the Wikidata project, and Wikia
> has partnered directly on VisualEditor development and is generally
> striving to increase visibility of its open source modifications to
> MediaWiki.
>
> At WMF, this has increasingly raised the question how the architecture
> of Wikimedia’s technical infrastructure can be evolved at this new,
> larger scale, and how we can bring more voices into that conversation.
> I've shared this note with the architects ahead of time and taken some
> initial feedback into account.
>
> Rob Lanphier has taken a lead role in giving the RFC process a kick in
> the pants as a solid, asynchronous, transparent process for organizing
> and resolving technical proposals. Brion, Tim and Mark are explicitly
> listed as the three individuals who can close an RFC (interpreting or
> helping reach consensus, or making an informed decision where there’s
> a lack of community participation), and have helped clear the RFC
> backlog and evolve the architecture guidelines. In addition, Rob is
> organizing the MediaWiki architecture summit in January, where we can
> talk about some of the most pressing or contentious architectural
> questions in person.
>
> However, Brion, Tim and Mark are not infinitely scalable, nor are they
> immortal (except in our hearts). They can’t be in every conversation,
> know every part of Wikimedia’s technical ecosystem, review every RFC,
> etc. We also have many other deeply talented technical contributors,
> including some who have many years of experience in our technical
> context specifically -- not just at WMF. Beyond just making technical
> decisions, architectural leadership creates opportunities for
> mentorship, modeling and nurturing the kind of behavior we want to
> foster in our technical community.
>
> So how should this role evolve going forward? Some possible paths (you
> know I like to present options ;-):
>
> Option A: We change nothing and don't promote any new people into
> architect roles for a while. I truly don’t think this is an option for
> much longer -- we need to find better ways to encourage some of our
> other capable technical contributors to feel ownership over
> Wikimedia’s technical direc

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Jeroen De Dauw]

Hey,

> * MediaWiki is not a shining beacon of good architecture. I'd argue it
> > should mostly be considered as a big blob of generally badly designed
> > legacy code
>
> This has nothing to do with the subject at hand.
>

It does, as it implies serious mistakes where made in the past, and that
one should not be religious about existing practices being the true one
way. And it is relevant for some of the other thoughts I listed when
thinking through their implications.

Cheers

--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Petr Bena]

So that's why suddenly I started receiving these email requests :D

On Wed, Nov 6, 2013 at 2:24 PM, MZMcBride  wrote:
> Hi.
>
> Our Bugzilla installation at  currently
> restricts the capabilities of new users as a knee-jerk response to prior
> Bugzilla-related vandalism. There are further details at
> .
>
> Increasingly new users are making manual requests to be assigned to bugs,
> as they cannot edit others' bugs by default. This is problematic and
> disruptive to development efforts.
>
> My suggestion is to re-add the "editbugs" user right to new users by
> default (revert the old settings adjustment). Otherwise, an acceptable
> workaround needs to be found.
>
> MZMcBride
>
>
>
> ___
> 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] New Bugzilla users have restricted accounts

[Thehelpfulone]

On 6 November 2013 13:24, MZMcBride  wrote:

> Our Bugzilla installation at  currently
> restricts the capabilities of new users as a knee-jerk response to prior
> Bugzilla-related vandalism. There are further details at
> .
>

My suggestion is to re-add the "editbugs" user right to new users by
> default (revert the old settings adjustment). Otherwise, an acceptable
> workaround needs to be found.
>

Given that the majority of the vandalism occurred in 2011, I think that
sufficient time has passed for us to re-add the right to all new users, and
if we have issues with vandalism in the future, then we can re-assess and
see what other options we can consider (such as some implementation of
"autoconfirmed" as suggested at <
https://bugzilla.wikimedia.org/show_bug.cgi?id=40497#c12>).

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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Rob Lanphier]

On Wed, Nov 6, 2013 at 5:24 AM, MZMcBride  wrote:

> Our Bugzilla installation at  currently
> restricts the capabilities of new users as a knee-jerk response to prior
> Bugzilla-related vandalism. There are further details at
> .
>


As I recall, Mark Hershberger and Ariel Glenn were the ones that dealt with
most of the aftermath of the attacks that we received that ultimately led
to it being turned off.  It was not a knee jerk response.  We temporarily
turned it off and turned it back on a few days later, only to have dozens
(hundreds?) of bugs altered in a way that was not easily reversed.

In consulting with the Bugzilla developers (I believe I may have sent a
public mail about this to their list), their answer was essentially that
Bugzilla was never designed for giving editbugs to untrusted users, and
that by doing so, we had what was coming to us.

We tried reversing it several times, and each time were rewarded with an
arduous cleanup task.  We gave up trying after months.  So, calling it
"kneejerk" is simply wrong.  We had a determined vandal who may still be
among us, and will likely exploit whatever loophole we open up.


Increasingly new users are making manual requests to be assigned to bugs,
> as they cannot edit others' bugs by default. This is problematic and
> disruptive to development efforts.
>
> My suggestion is to re-add the "editbugs" user right to new users by
> default (revert the old settings adjustment). Otherwise, an acceptable
> workaround needs to be found.
>

I don't think we can pretend that the vandalism issue is solved, because it
isn't.  Bugzilla doesn't have the vandalism fighting tools that MediaWiki
does.

We can certainly do something different than what we're doing, though.  It
should be easy to get editbugs; just not so easy that a vandal can get it.

Anyone have any ideas how to mitigate the vandalism problem?

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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Dan Garry]

I don't want anything to stand in the way of good users

Perhaps something similar to autoconfirmed as Thehelpfulone suggested, i.e.
X total edits across all Wikimedia projects (or on a single Wikimedia
project), and account was created Y days ago. There are details to work
through with that (e.g. how do we verify bugzilla user a...@b.com owns the
global account they say they do?), but I think it's a good approach.

Dan


On 6 November 2013 15:38, Rob Lanphier  wrote:

> On Wed, Nov 6, 2013 at 5:24 AM, MZMcBride  wrote:
>
> > Our Bugzilla installation at  currently
> > restricts the capabilities of new users as a knee-jerk response to prior
> > Bugzilla-related vandalism. There are further details at
> > .
> >
>
>
> As I recall, Mark Hershberger and Ariel Glenn were the ones that dealt with
> most of the aftermath of the attacks that we received that ultimately led
> to it being turned off.  It was not a knee jerk response.  We temporarily
> turned it off and turned it back on a few days later, only to have dozens
> (hundreds?) of bugs altered in a way that was not easily reversed.
>
> In consulting with the Bugzilla developers (I believe I may have sent a
> public mail about this to their list), their answer was essentially that
> Bugzilla was never designed for giving editbugs to untrusted users, and
> that by doing so, we had what was coming to us.
>
> We tried reversing it several times, and each time were rewarded with an
> arduous cleanup task.  We gave up trying after months.  So, calling it
> "kneejerk" is simply wrong.  We had a determined vandal who may still be
> among us, and will likely exploit whatever loophole we open up.
>
>
> Increasingly new users are making manual requests to be assigned to bugs,
> > as they cannot edit others' bugs by default. This is problematic and
> > disruptive to development efforts.
> >
> > My suggestion is to re-add the "editbugs" user right to new users by
> > default (revert the old settings adjustment). Otherwise, an acceptable
> > workaround needs to be found.
> >
>
> I don't think we can pretend that the vandalism issue is solved, because it
> isn't.  Bugzilla doesn't have the vandalism fighting tools that MediaWiki
> does.
>
> We can certainly do something different than what we're doing, though.  It
> should be easy to get editbugs; just not so easy that a vandal can get it.
>
> Anyone have any ideas how to mitigate the vandalism problem?
>
> Rob
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Dan Garry]

Pre-emptive send wins again. That was meant to be "I don't want anything to
stand in the way of good users filing bug reports, but we need to be aware
of the previous issues that led to the current situation."

Dan


On 6 November 2013 15:45, Dan Garry  wrote:

> I don't want anything to stand in the way of good users
>
> Perhaps something similar to autoconfirmed as Thehelpfulone suggested,
> i.e. X total edits across all Wikimedia projects (or on a single Wikimedia
> project), and account was created Y days ago. There are details to work
> through with that (e.g. how do we verify bugzilla user a...@b.com owns the
> global account they say they do?), but I think it's a good approach.
>
> Dan
>
>
> On 6 November 2013 15:38, Rob Lanphier  wrote:
>
>> On Wed, Nov 6, 2013 at 5:24 AM, MZMcBride  wrote:
>>
>> > Our Bugzilla installation at  currently
>> > restricts the capabilities of new users as a knee-jerk response to prior
>> > Bugzilla-related vandalism. There are further details at
>> > .
>> >
>>
>>
>> As I recall, Mark Hershberger and Ariel Glenn were the ones that dealt
>> with
>> most of the aftermath of the attacks that we received that ultimately led
>> to it being turned off.  It was not a knee jerk response.  We temporarily
>> turned it off and turned it back on a few days later, only to have dozens
>> (hundreds?) of bugs altered in a way that was not easily reversed.
>>
>> In consulting with the Bugzilla developers (I believe I may have sent a
>> public mail about this to their list), their answer was essentially that
>> Bugzilla was never designed for giving editbugs to untrusted users, and
>> that by doing so, we had what was coming to us.
>>
>> We tried reversing it several times, and each time were rewarded with an
>> arduous cleanup task.  We gave up trying after months.  So, calling it
>> "kneejerk" is simply wrong.  We had a determined vandal who may still be
>> among us, and will likely exploit whatever loophole we open up.
>>
>>
>> Increasingly new users are making manual requests to be assigned to bugs,
>> > as they cannot edit others' bugs by default. This is problematic and
>> > disruptive to development efforts.
>> >
>> > My suggestion is to re-add the "editbugs" user right to new users by
>> > default (revert the old settings adjustment). Otherwise, an acceptable
>> > workaround needs to be found.
>> >
>>
>> I don't think we can pretend that the vandalism issue is solved, because
>> it
>> isn't.  Bugzilla doesn't have the vandalism fighting tools that MediaWiki
>> does.
>>
>> We can certainly do something different than what we're doing, though.  It
>> should be easy to get editbugs; just not so easy that a vandal can get it.
>>
>> Anyone have any ideas how to mitigate the vandalism problem?
>>
>> Rob
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
>
> --
> Dan Garry
> Associate Product Manager for Platform
> Wikimedia Foundation
>



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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Brian Wolff]

I like the idea of more liberally (and perhaps automatically) giving out
the right. As it stands, I'm not even sure who can give out editbugs other
than Andre. In any case I understand it to be a very small number who can.
For a start it would be nice if pretty much any active developer could.
Perhaps even anyone with the editbugs right.

Automated solution would be even better. I suppose one could implement
Dan's suggestion by having a script that sends part A of  a token to your
bugzilla email, part b to a your mediawiki email, and asks the user to
produce both.

-bawolff
On 2013-11-06 11:46 AM, "Dan Garry"  wrote:
>
> I don't want anything to stand in the way of good users
>
> Perhaps something similar to autoconfirmed as Thehelpfulone suggested,
i.e.
> X total edits across all Wikimedia projects (or on a single Wikimedia
> project), and account was created Y days ago. There are details to work
> through with that (e.g. how do we verify bugzilla user a...@b.com owns the
> global account they say they do?), but I think it's a good approach.
>
> Dan
>
>
> On 6 November 2013 15:38, Rob Lanphier  wrote:
>
> > On Wed, Nov 6, 2013 at 5:24 AM, MZMcBride  wrote:
> >
> > > Our Bugzilla installation at  currently
> > > restricts the capabilities of new users as a knee-jerk response to
prior
> > > Bugzilla-related vandalism. There are further details at
> > > .
> > >
> >
> >
> > As I recall, Mark Hershberger and Ariel Glenn were the ones that dealt
with
> > most of the aftermath of the attacks that we received that ultimately
led
> > to it being turned off.  It was not a knee jerk response.  We
temporarily
> > turned it off and turned it back on a few days later, only to have
dozens
> > (hundreds?) of bugs altered in a way that was not easily reversed.
> >
> > In consulting with the Bugzilla developers (I believe I may have sent a
> > public mail about this to their list), their answer was essentially that
> > Bugzilla was never designed for giving editbugs to untrusted users, and
> > that by doing so, we had what was coming to us.
> >
> > We tried reversing it several times, and each time were rewarded with an
> > arduous cleanup task.  We gave up trying after months.  So, calling it
> > "kneejerk" is simply wrong.  We had a determined vandal who may still be
> > among us, and will likely exploit whatever loophole we open up.
> >
> >
> > Increasingly new users are making manual requests to be assigned to
bugs,
> > > as they cannot edit others' bugs by default. This is problematic and
> > > disruptive to development efforts.
> > >
> > > My suggestion is to re-add the "editbugs" user right to new users by
> > > default (revert the old settings adjustment). Otherwise, an acceptable
> > > workaround needs to be found.
> > >
> >
> > I don't think we can pretend that the vandalism issue is solved,
because it
> > isn't.  Bugzilla doesn't have the vandalism fighting tools that
MediaWiki
> > does.
> >
> > We can certainly do something different than what we're doing, though.
 It
> > should be easy to get editbugs; just not so easy that a vandal can get
it.
> >
> > Anyone have any ideas how to mitigate the vandalism problem?
> >
> > Rob
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
>
>
> --
> Dan Garry
> Associate Product Manager for Platform
> 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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Chad]

On Wed, Nov 6, 2013 at 7:38 AM, Rob Lanphier  wrote:

> On Wed, Nov 6, 2013 at 5:24 AM, MZMcBride  wrote:
>
> > Our Bugzilla installation at  currently
> > restricts the capabilities of new users as a knee-jerk response to prior
> > Bugzilla-related vandalism. There are further details at
> > .
> >
>
>
> As I recall, Mark Hershberger and Ariel Glenn were the ones that dealt with
> most of the aftermath of the attacks that we received that ultimately led
> to it being turned off.  It was not a knee jerk response.  We temporarily
> turned it off and turned it back on a few days later, only to have dozens
> (hundreds?) of bugs altered in a way that was not easily reversed.
>
> In consulting with the Bugzilla developers (I believe I may have sent a
> public mail about this to their list), their answer was essentially that
> Bugzilla was never designed for giving editbugs to untrusted users, and
> that by doing so, we had what was coming to us.
>
> We tried reversing it several times, and each time were rewarded with an
> arduous cleanup task.  We gave up trying after months.  So, calling it
> "kneejerk" is simply wrong.  We had a determined vandal who may still be
> among us, and will likely exploit whatever loophole we open up.
>
>
> Increasingly new users are making manual requests to be assigned to bugs,
> > as they cannot edit others' bugs by default. This is problematic and
> > disruptive to development efforts.
> >
> > My suggestion is to re-add the "editbugs" user right to new users by
> > default (revert the old settings adjustment). Otherwise, an acceptable
> > workaround needs to be found.
> >
>
> I don't think we can pretend that the vandalism issue is solved, because it
> isn't.  Bugzilla doesn't have the vandalism fighting tools that MediaWiki
> does.
>
> We can certainly do something different than what we're doing, though.  It
> should be easy to get editbugs; just not so easy that a vandal can get it.
>
> Anyone have any ideas how to mitigate the vandalism problem?
>
>
How about we make editbugs self-granting? That is, if you've got editbugs
you can give it to others (like we did with Coder a few years ago). It works
pretty well, scales infinitely, and tends to protect itself against abuse.

If the vandal suddenly reappears, it's pretty easy to figure out who they
are
or who let them in at that point.

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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Brion Vibber]

On Wed, Nov 6, 2013 at 7:54 AM, Chad  wrote:

> How about we make editbugs self-granting? That is, if you've got editbugs
> you can give it to others (like we did with Coder a few years ago). It
> works
> pretty well, scales infinitely, and tends to protect itself against abuse.
>
> If the vandal suddenly reappears, it's pretty easy to figure out who they
> are
> or who let them in at that point.
>

+∞ I endorse this notion.

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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Andre Klapper]

In general: I am happy to change Bugzilla settings, whatever is agreed
on in the end.

On Wed, 2013-11-06 at 07:38 -0800, Rob Lanphier wrote:
> On Wed, Nov 6, 2013 at 5:24 AM, MZMcBride  wrote:
> 
> > Our Bugzilla installation at  currently
> > restricts the capabilities of new users as a knee-jerk response to prior
> > Bugzilla-related vandalism. There are further details at
> > .
> >
> 
> 
> As I recall, Mark Hershberger and Ariel Glenn were the ones that dealt with
> most of the aftermath of the attacks that we received that ultimately led
> to it being turned off.  It was not a knee jerk response.  We temporarily
> turned it off and turned it back on a few days later, only to have dozens
> (hundreds?) of bugs altered in a way that was not easily reversed.

Bugzilla does not allow centrally reverting all actions by a specific
person: https://bugzilla.mozilla.org/show_bug.cgi?id=735213

> In consulting with the Bugzilla developers (I believe I may have sent a
> public mail about this to their list), their answer was essentially that
> Bugzilla was never designed for giving editbugs to untrusted users, and
> that by doing so, we had what was coming to us.
[...]
> We can certainly do something different than what we're doing, though.  It
> should be easy to get editbugs; just not so easy that a vandal can get it.
> 
> Anyone have any ideas how to mitigate the vandalism problem?

Refering to the recent problem in Wikimedia Bugzilla, setting the
assignee field is only possible when having "editbugs" permissions.
There are no permissions which are more fine-grained and I could not
find a request upstream asking for a specific "be able to change the
assignee without editbugs permissions" request (plus docs suck anyway,
see https://bugzilla.mozilla.org/show_bug.cgi?id=481859 ).

I have no good spontaneous idea how to solve this problem. 
My guess is hacking the code as described in
http://www.bugzilla.org/docs/4.4/en/html/cust-change-permissions.html
I've asked on the upstream mailing list:
https://groups.google.com/forum/#!topic/mozilla.support.bugzilla/6GCB7ufa7nc


The wider picture regarding vandalism:
Related unresolved upstream bugs refering to blocking IPs:
https://bugzilla.mozilla.org/show_bug.cgi?id=904698
https://bugzilla.mozilla.org/show_bug.cgi?id=536110
Mozilla Bugzilla had a spam problem a few days ago, and they ended up
temporarily disabling account creation for specific domains *manually*,
instead of trying to fix it properly in
https://bugzilla.mozilla.org/show_bug.cgi?id=467763


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] Architectural leadership in Wikimedia's technical community

[Chad]

On Wed, Nov 6, 2013 at 7:13 AM, Brion Vibber  wrote:

> My brief thoughts:
>
> * It makes sense to have a handful of folks as a core review & planning
> group.
>
>
Agreed.


> * However, I would consider avoiding using the term "Architect" for its
> members as it's easily conflated with existing WMF job titles. I think job
> titles are pretty unreliable indicators at the best of times, and of course
> can be wildly inconsistent across companies.
>
>
This.


> * I've got no particular patience for over-formal community processes like
> Wikipedia adminship voting, nor interest in replicating those processes.
>
>
A million times this.


> While there are plenty of problems with the traditional FOSS concept of
> "meritocracy", I still have great affection for the "do-it-ocracy" notion
> that folks who actually get stuff done should be recognized as fulfilling
> the roles they are performing.
>
>
People who do things are more valuable than people who only
voice armchair opinions :)


> As such, I'd recommend a slightly more formal role for additional "lead
> reviewers" or "module owners" in the code review & RFC processes; not as
> *gatekeepers* so much as to provide a next-step for getting something
> moving that's stalled -- a potential contributor or a team within WMF
> working on a feature should be able to easily determine who to talk to
> about getting a go/no-go or advice on what to do in case of a no-go.
>
> (For comparison, I occasionally write patches for Firefox and Firefox OS;
> they have a *really full* bug tracker and your only hope of getting a patch
> reviewed is to actually request review from a particular person. A list of
> module owners like  is a
> lifesaver for a casual contributor who doesn't know everybody on the
> Mozilla teams.)
>

So yeah, I think that's the idea behind the "Maintainers" page
. It could be more
complete. And finding a way to involve these stakeholders in the RFC process
could certainly be beneficial.

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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Mark A. Hershberger]

On 11/06/2013 11:16 AM, Andre Klapper wrote:
> Bugzilla does not allow centrally reverting all actions by a specific
> person: https://bugzilla.mozilla.org/show_bug.cgi?id=735213

Luckily, though, it does track actions by user.  As a result, I was able
to revert the vandalism.  But it does seem like that ("revert all
actions by this user") should be something in Bugzilla itself.

Mark.

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

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Mark A. Hershberger]

Thank you, Quim, for trying to focus this discussion on the MediaWiki
community instead of just the WMF.  This is a very valuable thing.

That, with Brion's "do-it-ocracy" (which assumes, I think, that we're
encouraging and enabling more people to "do it") are excellent
approaches to this "who are the architects?" problem.

Finally, Jeroen is right that MW isn't a pristine example of excellent
architecture.  Still, this is what we have.  While we shouldn't enshrine
bad practices for perpetuity, it isn't helpful to pull the rug out from
under the existing infrastructure.  That is like rewriting MW in Java
(http://meatballwiki.org/wiki/RewriteMediawikiInJava), Python, or Perl.

All that said, I'm not too concerned with the titles the WMF gives
people.  I am interested in the answers to the questions Quim had, though:

On 11/06/2013 02:33 AM, Quim Gil wrote:
> Do the three architects consider themselves assuming this role as WMF
> employees or as community members?
> 
> Do they consider their roles to be part of a MediaWiki centric
> meritocracy or a Wikimedia centric meritocracy?
> 
> What is their opinion about moving forward their current team of three?
> 
> Because these three long-term contributors have earned their community
> reputation and are clearly smart, the chances are that many of us would
> agree with any common answer they would agree with themselves.

Thanks,

Mark.

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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Quim Gil]

On 11/06/2013 07:24 AM, Petr Bena wrote:
> So that's why suddenly I started receiving these email requests :D

No, you are getting suddenly these emails from a group of students at
http://foss.amrita.ac.in because a mentor told them to do so. We have
explained the right process to them (asking in the bug report itself
instead of sending private emails).

This is what Andre and me found out after asking to some of these
potential volunteers. They are getting the bugs assigned, as requested.
Let's see how many have the skills and determination to resolve the bugs.

After reading all this thread, I would be cautious changing the current
setup. New users can't assign bugs to them, but nothing is stopping them
to comment their intentions on the report itself, and actually fix the
bug. If a potential contributor doesn't understand this (yet), there is
also a chance that s/he won't be ready (yet) to fix the bug either,
because that will probably require understanding other, more complex steps.

This might be one of those barriers that happen to be useful to
understand better the complexity of a first task. I'm not sure we would
get a significant benefit by removing it, even if we wouldn't get any of
the vandalism that caused the introduction of the barrier in the first
place.

-- 
Quim Gil
Technical Contributor Coordinator @ 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

Re: [Wikitech-l] Architectural leadership in Wikimedia's technical community

[Brion Vibber]

On 11/06/2013 02:33 AM, Quim Gil wrote:

> > Do the three architects consider themselves assuming this role as WMF
> > employees or as community members?
>

For myself -- I've been a Wikipedia & MediaWiki community contributor since
long before there was a Wikimedia Foundation. I still think of WMF as the
new kid on the block... ;)

That said, my employment at WMF is what pays my bills and ensures I keep
the majority of my attention poking at the Wikipedia and MediaWiki
ecosystem (currently concentrating on the mobile world with a slice of
general maintenance, code review, and architecture planning). When I spent
a year and a half working at another company, I did find I had much less
time to spend on MediaWiki.


> > Do they consider their roles to be part of a MediaWiki centric
> > meritocracy or a Wikimedia centric meritocracy?
>

MediaWiki's development is traditionally Wikipedia- and Wikimedia-centric
(not necessarily Wikimedia Foundation-centric); it was created for
Wikipedia and I personally got involved in it to support Wikipedia's
various multilingual editions. Generalized usage of MW has always been a
secondary, though important, goal, and I expect Wikipedia/Wikimedia will
continue to be central in MW's development for the forseeable future, even
assuming we put a lot more effort into third-party support (which I think
we should!)

I also caution against use of the "meritocracy" term, as I think it's
pretty loaded and has a history of enabling stagnation and ingraining of
cabals and antisocial behavior in free software communities. While I
certainly like to think I've earned my fancy title with years of hard work,
there are strong social/popularity and random-event components in any kind
of ranking like this.


> > What is their opinion about moving forward their current team of three?
>

I'm not sure the "architects" really exist as a team of three; I feel like
that's a fairly arbitrary selection of longtime contributors who,
currently, have "architect" in their job title.

There's similarity in subsets of what we do, and some direct overlap -- Tim
and I both comment on code and code designs and do the occasional big RFC
review session; Tim and Mark both comment on and help debug ops and
performance issues -- but we're not the 3 Musketeers... :)


> > Because these three long-term contributors have earned their community
> > reputation and are clearly smart, the chances are that many of us would
> > agree with any common answer they would agree with themselves.
>

:D

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

Re: [Wikitech-l] Memento Extension for MediaWiki: Advice on Further Development

[Remco de Boer]

Good! I'd like to run some tests on some of our data (we run several SMW
instances). I will have to prepare a separate environment with the latest
versions of MW and SMW and the Memento extension. Nothing too difficult,
but it'll probably take some time.


On Tue, Nov 5, 2013 at 1:48 AM, Herbert Van de Sompel wrote:

> On Nov 4, 2013, at 14:24, Remco de Boer  wrote:
> > Hi Shawn,
> >
> >
> > I'm currently working on the Memento Extension for Mediawiki, as
> announced
> >> earlier today by Herbert Van de Sompel.
> >
> > This is very exciting! Coincidentally, at last week's SMWCon (the
> Semantic
> > MediaWiki conference) in Berlin I gave a presentation to argue that we
> need
> > some sort of 'time travelling' feature (slides are available at
> > http://slidesha.re/1iIf3F9). One of the other participants also pointed
> out
> > the Memento protocol.
> >
> > Are you familiar with Semantic MediaWiki (
> http://www.semantic-mediawiki.org/)
> > as an extension to MediaWiki? I'm curious what it would take to let SMW
> > play nice together with Memento.
>
> Before announcing the Memento extension to this list we tested it with a
> locally installed Semantic MediaWiki and all seemed OK. It would be great
> if someone could test it on a live one with actual real data. We got in
> touch with the people behind http://neurolex.org/wiki/Main_Page but they
> are running an older MediaWiki version and are not in a hurry to upgrade
> because they have a lot of extensions.
>
> From the early days of Memento, we have been very interested in semantic
> web, linked data applications of the Memento protocol. See, for example:
> - http://arxiv.org/abs/1003.3661 - illustrates the power of the protocol
> to do time series analysis across versions of linked data description (in
> DBpedia)
> - http://mementoweb.org/depot/native/dbpedia/ - the DBpedia archive that
> we operate and that is Memento compliant -
>
> Greetings
>
> Herbert
>
> >
> > Kind regards,
> >
> > Remco de Boer
> > ___
> > 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] Architectural leadership in Wikimedia's technical community

[Quim Gil]

On 11/06/2013 12:30 PM, Brion Vibber wrote:

>>> Do they consider their roles to be part of a MediaWiki centric
>>> meritocracy or a Wikimedia centric meritocracy?

(...)

> I also caution against use of the "meritocracy" term, as I think it's
> pretty loaded and has a history of enabling stagnation and ingraining of
> cabals and antisocial behavior in free software communities. While I
> certainly like to think I've earned my fancy title with years of hard work,
> there are strong social/popularity and random-event components in any kind
> of ranking like this.

Agreed. I meant "meritocracy" in its unloaded form and I'm happy to use
whatever alternative term. A typical open source project has committers
and maintainers, roles that we have as well. They also have a release
team, which we have as well. Some have a formal project leader
(temporary or for life, individual or plural), some have none, as it is
our case now.

Is this what this thread is all about? Having a project lead role to
make decisions when maintainers alone are not enough?

Wikimedia vs MediaWiki centric... yes, it's complicated--and then again
perhaps it's not. In any case, the structure and roles of this project
should come from within and be independent from the structure and roles
of the WMF.

-- 
Quim Gil
Technical Contributor Coordinator @ 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

Re: [Wikitech-l] Architecture RFC review meeting, Nov 6

[Quim Gil]

Hi,

> https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-11-06

We just finished the meeting, and you can find the notes at

http://integration-meetbot.instance-proxy.wmflabs.org/wikimedia-meetbot/2013/wikimedia-meetbot.2013-11-06-22.03.html

We discussed TitleValue, Configuration database, and Password
requirements. We didn't have time to review Allow styling in
templates.

The next RFC review meeting is planned for November 20. Details to be
posted here and at
https://www.mediawiki.org/wiki/Architecture_meetings

Thank you for your participation! Feedback to improve our future
meetings is welcome.

PS: hashar says that the current location of these notes is not the
most reliable, but what is the alternative? I will post the full log
in the RFC wiki pages just in case. The relevant details should be
documented there anyway.

-- 
Quim Gil
Technical Contributor Coordinator @ 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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[MZMcBride]

Rob Lanphier wrote:
>We tried reversing it several times, and each time were rewarded with an
>arduous cleanup task.  We gave up trying after months.  So, calling it
>"kneejerk" is simply wrong.  We had a determined vandal who may still be
>among us, and will likely exploit whatever loophole we open up.

Okay, I apologize for using that term.

>We can certainly do something different than what we're doing, though.  It
>should be easy to get editbugs; just not so easy that a vandal can get it.

Okay, let's. I proposed reverting the settings change. You don't like that
idea. Your turn. :-)

MZMcBride



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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[MZMcBride]

Quim Gil wrote:
>On 11/06/2013 07:24 AM, Petr Bena wrote:
>> So that's why suddenly I started receiving these email requests :D
>
>No, you are getting suddenly these emails from a group of students at
>http://foss.amrita.ac.in because a mentor told them to do so. We have
>explained the right process to them (asking in the bug report itself
>instead of sending private emails).

This makes no sense to me. The issue is the extra step altogether.

---
Mentor practice: private e-mail users to assign bug, bug gets assigned,
bugspam about bug being assigned

Your proposed practice: asking to be assigned on bug, bugspam about bug
being commented on, bug gets assigned, bugspam about bug being assigned

Previous practice (pre-vandalism lockdown NEVER FORGET): bug gets
assigned, bugspam about bug being assigned
---

I prefer the previous practice. Your proposal effectively just moves the
mail from my main inbox to the Bugzilla folder. I suppose it's a slight
improvement, but it misses the point that the overall workflow is broken.

MZMcBride



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

Re: [Wikitech-l] Module storage is coming

[Ori Livneh]

On Sun, Nov 3, 2013 at 5:27 PM, Ori Livneh  wrote:
> How can I test it?
> --
> Glad you asked! Module storage is enabled by default on the beta
> cluster, and on test & test2 wikis.

It's also enabled on MediaWiki.org now, the last such wiki before
doing performance testing. I figured it'd be OK because it has been
running on beta / test / test2 for over a week with no bugs being
reported. Please report back if you notice anything good or bad.

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

Re: [Wikitech-l] Optimizing the deployment train schedule

[Greg Grossmeier]

> tldr; I like a modified Option C, but also propose a very different
> Option D that I think would also be good, either now or as the next next
> step.

This Monday is a US Holiday, so no deploys that day. Seems like a
reasonable week to start on the Option C modification (ie: move Monday's
deploy to Tuesday).

Let's do that.

I'd still like to move around the wikis in the various groups/phases,
but that can wait (and will need to, as we need to see which ones want
to move where).

Greg

-- 
| 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] Architectural leadership in Wikimedia's technical community

[Erik Moeller]

On Wed, Nov 6, 2013 at 7:13 AM, Brion Vibber  wrote:

> * It makes sense to have a handful of folks as a core review & planning
> group.
>
> * However, I would consider avoiding using the term "Architect" for its
> members as it's easily conflated with existing WMF job titles. I think job
> titles are pretty unreliable indicators at the best of times, and of course
> can be wildly inconsistent across companies.

Yeah, that makes sense to me. How do you propose that core review &
planning group be comprised? You say "a handful of folks", do you mean
that literally, or are you talking about a comprehensive maintainers
list like the one at
https://www.mediawiki.org/wiki/Developers/Maintainers ? If it's a
significantly smaller subset, perhaps the current architects should
appoint some folks as lieutenants, either Linux-style or on an
as-needed basis?

> As such, I'd recommend a slightly more formal role for additional "lead
> reviewers" or "module owners" in the code review & RFC processes

Would that be the same as the "core review & planning group" you refer to above?

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

Re: [Wikitech-l] New Bugzilla users have restricted accounts

[Rob Lanphier]

On Wed, Nov 6, 2013 at 4:18 PM, MZMcBride  wrote:
> Rob Lanphier wrote:
> >We can certainly do something different than what we're doing, though.  It
>
> >should be easy to get editbugs; just not so easy that a vandal can get it.
>
> Okay, let's. I proposed reverting the settings change. You don't like that
> idea. Your turn. :-)

We keep the status quo.  Your turn  :-P

I like the idea of giving everyone who has editbugs the right to give
other people the editbugs permission.  That's certainly worth a try
assuming it's possible to configure.

BTW, here's the original thread from when it got bad:
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/56816

A couple of relevant Bugzilla bugs come up in that thread:
Bug 363346: "show activity should have an option to migrate or revert
a set of changes"
https://bugzilla.mozilla.org/show_bug.cgi?id=363346

Bug 704753: "Throttle new bug creation, comments, and modifications
for some accounts"
https://bugzilla.mozilla.org/show_bug.cgi?id=704753

If we had these two, we'd be golden for opening it all of the way back
up.  Even if we just had 704753, that could limit the scope of a
cleanup effort quite a bit.

Rob

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

[Wikitech-l] Language Engineering IRC Office Hour on November 13, 2013 at 1500 UTC

[Runa Bhattacharjee]

[x-posted]

Hello,

The Wikimedia Language Engineering team will be hosting an IRC office
hour on Wednesday, November 13, 2013 between 15:00 - 16:00 UTC on
#wikimedia-office. (See below for timezone conversion and other details.)
We will be talking about some of our recent and upcoming projects and then
taking questions for the remaining time.

We also look forward to hear about anything that needs our attention.
Questions and other concerns can also be sent to me directly before the
event. See you there!

Thanks
Runa

=== Event Details ===

What: WMF Language Engineering Office hour
When: November 13, 2013 (Wednesday). 1500-1600 UTC
http://www.timeanddate.com/worldclock/fixedtime.html?iso=20131113T1500
Where: IRC Channel #wikimedia-office on FreeNode

-- 
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Architecture RFC review meeting, Nov 6

[Ori Livneh]

On Wed, Nov 6, 2013 at 3:18 PM, Quim Gil  wrote:
> Hi,
>
>> https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-11-06
>
> We just finished the meeting, and you can find the notes at
>
> http://integration-meetbot.instance-proxy.wmflabs.org/wikimedia-meetbot/2013/wikimedia-meetbot.2013-11-06-22.03.html
>
> We discussed TitleValue, Configuration database, and Password
> requirements. We didn't have time to review Allow styling in
> templates.
>
> The next RFC review meeting is planned for November 20. Details to be
> posted here and at
> https://www.mediawiki.org/wiki/Architecture_meetings
>
> Thank you for your participation! Feedback to improve our future
> meetings is welcome.
>
> PS: hashar says that the current location of these notes is not the
> most reliable, but what is the alternative? I will post the full log
> in the RFC wiki pages just in case. The relevant details should be
> documented there anyway.

Ideally we'd publish these notes to MediaWiki.org. I note that the
upstream wishlist at https://wiki.debian.org/MeetBot has this item:
"Publish to a wiki page? (I'll do it if someone gives me wiki-posting
code)". Could be a nice side project.

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