cross-posting to the internal research + ee lists as other public graphs for these wikis might be affected by the replication issue.
Thanks for the heads up, Christian.
Dario
On Nov 1, 2013, at 4:12 PM, Christian Aistleitner <christian(a)quelltextlich.at> wrote:
> Hi,
>
> just a quick heads up that the analytics slave for s6 (frwiki, jawiki,
> ruwiki) seems to not be replicating since 2013-10-28 ~07:15. I filed
> an RT ticket. But if your scripts rely on the slave, expect the
> numbers to be off until the problem has been fixed.
>
> We know that at least the following graphs (and corresponding CSVs)
> are affected:
> http://gp.wmflabs.org/graphs/active_editors_total
> http://gp.wmflabs.org/graphs/frwiki_editor_counts
> http://gp.wmflabs.org/graphs/jawiki_editor_counts
> http://gp.wmflabs.org/graphs/ruwiki_editor_counts
>
> We'll rerun data aggregation for them after the problem has been
> fixed. So expect the numbers for >=2013-10-28 to jump after the fix.
>
> Best regards,
> Christian
>
>
>
> --
> ---- quelltextlich e.U. ---- \\ ---- Christian Aistleitner ----
> Companies' registry: 360296y in Linz
> Christian Aistleitner
> Gruendbergstrasze 65a Email: christian(a)quelltextlich.at
> 4040 Linz, Austria Phone: +43 732 / 26 95 63
> Fax: +43 732 / 26 95 63
> Homepage: http://quelltextlich.at/
> ---------------------------------------------------------------
> _______________________________________________
> Analytics mailing list
> Analytics(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/analytics
Hey guys,
Thought you might enjoy this interesting round-up of studies on the dynamics of online discussions from the New Yorker:
http://www.newyorker.com/online/blogs/elements/2013/10/the-psychology-of-on…
It touches on familiar topics related to anonymity, civility, accountability, tone and content of online comments -- with fascinating concepts such as the 'online disinhibition effect' and 'diffusion of responsibility'.
Is anyone familiar with the research studies cited in the article? Would you view them as reliable? Are there other important studies that relate to this topic?
Hope you find this helpful for your weekend reading :)
Fabrice
_______________________________
Fabrice Florin
Product Manager
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
Crossposting as this may be of interest :)
*Steven Zhang*
*cro0016(a)gmail.com*
---------- Forwarded message ----------
From: Steven Zhang <cro0016(a)gmail.com>
Date: 24 October 2013 08:26
Subject: Individual Engagement Grant proposal on Reimagining Wikipedia
Mentorship
To: English Wikipedia <wikien-l(a)lists.wikimedia.org>
Hello everyone,
An Individual Engagement Grant entitled "Reimagining Mentorship on
Wikipedia" is currently under review at
https://meta.wikimedia.org/wiki/Grants:IEG/Reimagining_Mentorship_on_Wikipe…
.
As part of our research into the best approach to take while pursuing this
grant, we would like to seek the input of all Wikimedia users - positive,
negative, and merely comments. We seek advice and input on best
approaches, previous attempts, current views on Wikimedia mentorship,
suggestions regarding implementation, and anything else that the community
can think of.
We look forward to hearing from everyone!
Best,
Steven Zhang
Hey all,
Today we deployed a new version of the onboarding UX we've been working on
for some time, using GettingStarted and GuidedTour. This is in "silent"
mode right now, and on Monday we'll be flipping the switch to deliver it
for 50% of new signups on English Wikipedia, as part of an A/B test.
To see what this looks like, just add ?gettingStartedReturn=true to any
link on enwiki, like...
- https://en.wikipedia.org/wiki/Otto_Lubarsch?gettingStartedReturn=truefor
what it looks like on an editable page
- https://en.wikipedia.org/wiki/Main_Page?gettingStartedReturn=true for
what it looks like on a page new users can't.
As our specification describes,[1] this test version with calls to action
will be delivered automatically to new users when they are redirected back
to where they were prior to signup. The control in our A/B test will be
sending all new users through Special:GettingStarted. You can find out more
about our hypotheses regarding this test on Meta.[2]
I'd appreciate any feedback people might have. A list of the current things
I want to see updated before Monday are on our publicly-viewable project
management tool, Trello.[3]
Many thanks!
1. https://www.mediawiki.org/wiki/Onboarding_new_Wikipedians#Proposed
2. https://meta.wikimedia.org/wiki/Research:OB6
3. https://trello.com/c/k4GksP18
--
Steven Walling,
Product Manager
https://wikimediafoundation.org/
Hi folks! I've been working for the past 7 months on an interactive guided
tour for new editors called '''The Wikipedia Adventure''', as part of a WMF
Individual Engagement Grant. The game is an experiment in teaching our
aspiring future editors in an educational but playful way.
*This week I need some '''alpha-testers''' to kick the tires and basically
try to break it. I'm interested in general impressions and suggestions of
course, but I'm really looking for gnarly, unexpected browser issues,
layout problems, workflow bugs, and other sundry errors that would prevent
people from playing through and having a positive experience.
*If you're able to spend 1-3 hours doing some quality assurance work this
week, you would have: a) my sincere gratitude b), a sparkly TWA barnstar,
c) special thanks in the game credits, and d) a chance to leave your mark
on Wikipedia's outreach puzzle and new editor engagement efforts.
*Please note that the game automatically sends edits to your own userspace
and it lets you know when that will happen. If you want, you can register
a new testing account just for the game, but it won't work properly unless
you're logged-in by step 8 of mission 1 (when it lets you register on the
fly).
You can try it out at http://enwp.org/WP:TWA and leave feedback at
http://enwp.org/WP:TWA/Feedback]].
Thanks much and cheers!
--Jake Orlowitz (Ocaasi)
I am posting this to wikitech-l, ee-l, and will cross-post this to https://bugzilla.wikimedia.org/show_bug.cgi?id=35306 because it's important to keep frank discussions in the open.
When I use to loaded words like "back-dooring" etc, I believe that no malice was intended and the discussions so far have been in good faith from all parties. I think people have a valid concern and want it addressed and are wondering honestly how decisions have been made. In particular, my decision to not allow the MassMessage Extension to roll out onto MediaWiki last week, since that occurred during a meeting that didn't even involve or derive have consultation (except ex-post-facto) with any product manager or engineer here.
Here is why I am inijating this thread:
1) https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=83188&old…
2) On Sep 30, 2013, at 4:25 PM, MZMcBride <z(a)mzmcbride.com> wrote:
> Hi Fabrice, Terry, and Howie,
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=35306#c19 is awaiting feedback (if you have any).
>
> MZ
3) https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=84903&old…
…
We have two separate but related bugs here:
https://bugzilla.wikimedia.org/show_bug.cgi?id=35306https://bugzilla.wikimedia.org/show_bug.cgi?id=52723
bug 35306 is an tracking bug MZMcBride posted for a solution to deal with EdwardsBot. I believe it dates to around the time I was first employed almost two years ago.
bug 52723 is a recent bug to deploy Legoktm's MassMessage extension as a solution to bug 35306, it is less than a month old there has been little public discussion, and until it appeared on the deploy calendar last week, I wasn't even aware of its existence.
The problem with moving on bug 52723 as a solution to bug 35306 is it commits Features Engineering to maintaining an extension that is a stop gap solution with no or very little discussion in a manner that doesn't serve a broad strategic goal about how messages, notifications, etc. should be handled on the wikis. To the first, maybe there is something wrong with my e-mail client, but I have yet to find this discussion on wikitech-l or anywhere outside the bug.
Because of the above, my view is that this solution is being back-doored in and just moves the "technical debt" from one sheet (the community and tool labs) to another that has even less capability. I am biased against that because the latter sheet (WMF Features Engineering) is my responsibility. This is just my view, I'm open for us coming to consensus on a solution for this bug, but what I have seen is not consensus.
It is along these lines that, I asked to remove MassMessage from the deploy calendar when it was added to the deploy calendar without discussion from Features, Design, or Product last week. After discussion during that Friday meeting among the EPMs, I compromised to let it to go out on two test wikis, but not on mediawiki. Nobody made the case that it should go out on mediawiki. I demurred because no person at the WMF, including me as Director of Features Engineering, should fiat a decision when unaware of the status of discussions involved.
But let frank: if this had been a WMF employee writing this extension, it wouldn't have made it to even the test wikis by a country mile. In fact, a lot of extensions have been written by employees and either have extensive discussion, review, and buy-in (e.g. GuidedTours), or have not been deployed (e.g. Etherpad, the org chart, BetaFeatures) even though much more work has been done on them.
I also don't like that WMF resources in Platform and Design are being spent to review something that has had no adequate discussion over in the annual plan, in anyone's 20% time, in any cross-team discussion, or public discussion on wikitech-l (There was a last minute thread in the Design list, I am not on the design list, nor should I be, and the Creative Director is new and the team is just trying to get their sea legs and some consideration to that needs to be done here). Furthermore, after further discussion, nearly all of Product felt I should not have compromised earlier because the following situation might occur: Having gotten it onto "the cluster" people would then move to back-door it into deployment on the basis that it's already on the cluster. Their prediction is occurring right now. This is a bogus argument because nobody agreed this should be on the cluster, it's just that nobody has reviewed it in a thorough enough manner to shout "NO!"
If necessary, I'm going to shout "NO!" at this moment.
Having said that, there is the larger issue of bug 35306 which has been sitting there unsolved for a while as well as the smaller issue of the month's work Legoktm and MZMcBride have already put into Bug 52723 and [[mw:Extension:MassMessage]] possibly going to waste if I keep blocking it. Besides, MZ is sitting there trying to hold everything up on his own shoulders with EdwardsBot, and we all know it.
…
Let me address the functionality overlap with Echo:
LanguageEngineering built their own parallel message/notification system before Echo that lives on Meta today. They commit to supporting their own parallel message/notification system, and I'm okay with it living outside Echo (where it currently does), but there is an understanding that they've basically committed to that work with no support from Features for the duration that it does live outside Echo.
In those lines, I'm glad that Platform has helped out here, but unless Platform is committing to support MassMessage indefinitely into the future and not just provide one-time security and deploy assistance, I'm not okay with them adding to Features work even though they've been super helpful to MZMcBride and Legoktm. If Dan Garry is willing to commit Platform to support MassMessage, I'll think the same precedent we've done with LE applies here.
Furthermore, before *in-echo, outside-echo, use-echo) for a solution to be bug 35306, it needs to actually exhibit product discipline. The WMF gets panned for having a "agile processes" but not actually doing so, but we do have some process and we need to at least apply the same product discipline that we apply everywhere else to this bug.
For example, features in MassMessage and EdwardsBot need to be addressed in a Must-Have, Should-Have, Could-Have, Won't-Have (MoSCoW) framework. Features like "mass delivery from a list" are probably a Must-Have; features like "cross-wiki notification" are probably a should-have, other features like "public over private notifications", "page-centric over user-centric" or "longer stream notifications" are either not a must-have or could have or are should-haves to be done outside Echo by a different service (bot) using the Echo API or some extension thereof. All that is a product issue, and I nor anyone in my team is in product. Those decisions should be done in discussion with the Product team and they should not be disintermediated from it, which they have been.
I understand that many people would like to see a solution to Bug 35306 would be great to have. I'd like to see a better Signpost notification system and a more generalized solution for newsletter delivery also! I'd also like a pony. But we have already committed resources and continue to commit resources without discussion from the people (Product Design, not Features Engineering) who have been tasked with this responsibility and are very good at these sort of thing. I hope everyone participating on this bug can see that dropping this bomb on a newly hired associate product manager is simply not cool on so many levels.
…
Here is my suggestion:
(This is thinking, not a directive so don't think of this as definitive or final, I'm seeking consensus here.)
First, bug 35306 is a long-standing request. I think it's important we get headway on this, but I hope others will be understanding if it doesn't happen immediately, so long as there is a commitment for this to happen.
(For perspective, Flow was first proposed years ago, and was added to the annual plan almost two years ago before their first actual development sprint was completed (end of this week!). Echo was first deployed almost 8 months ago and is still not out on all the wikis. BetaFeatures has been in discussion for months and is still not deployed, nor is the commitment to maintain inside Features and that has caused a lot of issues. Fixing things right right takes time because consensus takes time and open discussion.)
There is an RfP for student developer time for legoktm for things like this (Finding a solution for Bug 35306 but not [[mw:Extension:MassMessage]] because MassMessage would not be deployed if it was my own engineer). Benny Situ has been spending all his time supporting [[mw:Extension:Echo]] when he should balancing [[mw:Flow]] development time into Echo bug fixes and needs to spend at least one sprint (two weeks) solely getting up to speed on Flow before doing enhancements for [[wm:Echo]]. Furthermore, Echo is not deployed everywhere yet and is still rolling out (though I've been pushing up the timetable on this as I feel we're too slow here), so it can't reach the places that EdwardsBot cat.
After the above happen, I'd like Benny and Kunal to work together to add some of the functionality of EdwardsBot into Echo for mass message delivery. Because of this, I'm moving bug 35306 into Echo as an enhancement and raising it's priority.
In the meantime I'll be OK with leaving MassMessage on test and test2 wikis because the alternative would be to remove it from the cluster entirely. The experiences and code Kunal derives by that can inform the enhancement to Echo, as well as things it already does that find themselves outside Echo (Echo does not and should not post to talk pages). So I figure two stages:
1) wait for some things to happen: legoktm to get an RfP, Echo to be on all wikis, and Benny to do an entire Flow only sprint and balancing his time more effectively wrt Echo.
2) MoSCoW other features of MassMessage/EdwardsBot for integration into Echo
3) Enhance and deploy a first pass to Echo to allow some sort of mass notification from a wiki list
4) Some sort of cross wiki notification enhancement (requires a design pass)
5) Discuss how to implement must-have or should-have features of EdwardsBot that can't live in Echo (permanent log of events)?
6) Add those to plan and be done.
The above can occur independently or in parallel to the above. If Product thinks it cool to commit Platform's constrained engineering resources to deploying and supporting MassMessage Extension forever and use it to take advantage of Echo when the features roll out in some undefined future, consider this thinking moot or at least orthogonal to MassMessage. IMO, it is bad enough that something important like BetaFeatures is without a home, but my answer from Features is "No" for MassMessage. If this was my own engineer, I'd raise hell with them for this and yell at their Product Manager for not being a good steward of Platform's time.
Take care,
terry
terry chay 최태리
Director of Features Engineering
Wikimedia Foundation
“Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.”
p: +1 (415) 839-6885 x6832
m: +1 (408) 480-8902
e: tchay(a)wikimedia.org
i: http://terrychay.com/
w: http://meta.wikimedia.org/wiki/User:Tychay
aim: terrychay
So I asked Erik offline for some clarification on this thread, since a
number of people seem worried. To summarize:
* there is no existing or planned rule that WMF Features dept must sign off
on all extensions prior to deployment
* there is no existing or planned rule that WMF Features dept must maintain
all extensions prior to deployment
* there is no existing or planned rule that WMF Features dept can choose to
waive these requirements, because they don't exist in the first place
Existing and continued-to-be-planned policy is that someone, somewhere has
to maintain stuff to be deployed, but there's no specific rule on who.
-- brion
On Thu, Oct 3, 2013 at 6:50 PM, Terry Chay <tchay(a)wikimedia.org> wrote:
> On Oct 3, 2013, at 3:15 PM, Terry Chay <tchay(a)wikimedia.org> wrote:
>
> > The above can occur independently or in parallel to the above. If
> Product thinks it cool to commit Platform's constrained engineering
> resources to deploying and supporting MassMessage Extension forever and use
> it to take advantage of Echo when the features roll out in some undefined
> future, consider this thinking moot or at least orthogonal to MassMessage.
> IMO, it is bad enough that something important like BetaFeatures is without
> a home, but my answer from Features is "No" for MassMessage. If this was my
> own engineer, I'd raise hell with them for this and yell at their Product
> Manager for not being a good steward of Platform's time.
>
> Ori has stepped up and is willing to commit his time to help Legoktm in
> supporting MassMessage on an ongoing basis. According to the current
> standard of the above, there is no longer any block on bug 52723.
>
> Time still has to be made to handle the rollout, but I'm assuming what is
> already in-process in Platform, and Ori can assist beyond that.
>
> The requirement for extensions to be deployed has ALWAYS been that Features
> Engineering sign off on a commitment to maintain the extension. I've
> relaxed it
> to be: "If another engineering department in collaboration with product is
> willing to commit to it, Features will not block." I'd like to someday
> relax
> this further to: "If any engineering department or community development in
> collaboration with the other core competencies (features, product, design,
> and
> community) are willing to commit to it, no one should block." We are not
> there
> yet, and trying to rail against that is winning a battle at the cost of
> the war
> breaking down these silos and having shared ownership and responsibility
> in our
> organization, in our community, and in our movement.
>
> Please realize the current state of affairs is that new Extension deploy
> can be done under the following frameworks:
>
> 1) The traditional "Features signs off on all extensions" that has always
> been in place. For Features to sign off on this, like with our own
> engineering staff, we require collaboration and buy-in in affected areas
> like the product managers and designers who will lose productivity or might
> be retasked on this. We must be good stewards of each-others times, and I
> would not have permitted (and will not permit) my engineers to task
> Platform and Design engineers for MassMessage in the manner that has
> happened to date (water under the bridge at this point).
> 2) The above can and has been be bypassed on a directive from the VPE as
> was the case for BetaFeatures.
> 3) Like LanguageEngineering's use of TranslationNotifications instead of
> Echo, if another team consisting of engineering, product, and design is
> willing to commit to supporting on an ongoing basis, then extension deploy
> proceeds without the traditional rule of discussing Features. Note, in this
> example we have an assumption that the feature set of MassMessage is as-is
> so it currently doesn't involve Product or Design, nor does it require more
> engineering resources inside the WMF beyond Ori who is currently untasked.
>
> We still eventually want to reach the point where the criteria is not the
> amalgam of rules above but a simpler one based on intent, expertise-sharing
> and consensus-building: "If any engineering department or community
> developer in collaboration with the other core competencies (engineering,
> product, design, and community) are willing to commit to ongoing
> maintenance of a feature, then no one group should block it."
>
> We haven't reached there yet, and please realize that when me make
> exceptions as in this case, it compromises the larger picture of our need
> to break down these silos and create shared ownership and responsibility in
> the WMF, in our communities, and in the movement as a whole.
>
> Take care,
>
> terry
>
>
> terry chay 최태리
> Director of Features Engineering
> Wikimedia Foundation
> “Imagine a world in which every single human being can freely share in the
> sum of all knowledge. That's our commitment.”
>
> p: +1 (415) 839-6885 x6832
> m: +1 (408) 480-8902
> e: tchay(a)wikimedia.org
> i: http://terrychay.com/
> w: http://meta.wikimedia.org/wiki/User:Tychay
> aim: terrychay
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
Hi folks,
We just published a blog post with an update on the Notifications project:
https://blog.wikimedia.org/2013/10/01/notifications-launch-on-more-wikipedi…
Please share it with your community -- and let us know if you have any feedback or questions.
Thanks again to everyone who made this successful project possible!
Fabrice
P.S.: Sorry if you received this message twice, due to a technical snafu with our mail server. :(
_______________________________
Fabrice Florin
Product Manager
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
@fabriceflorin