Hi everyone,
WMF researchers have agreed to participate in an office hour about WMF research projects and methodologies.
The currently scheduled participants are:
* Aaron Halfaker, Research Analyst (contractor)
* Jonathan Morgan, Research Strategist (contractor)
* Evan Rosen, Data Analytics Manager, Global Development
* Haitham Shammaa, Contribution Research Manager
* Dario Taraborelli, Senior Research Analyst, Strategy
We'll meet on IRC in #wikimedia-office on April 22 at 1800 UTC. Please join us.
Pine
Hey all,
It's been a week or two since I gave an update here on what the Editor
Engagement Experiments (E3) team has deployed, so I wanted to share some
notes about what we've rolled out...
First up: the new *account creation and login* designs are being enabled as
the new default everywhere.[1] It's on about 30 projects so far, and will
be enabled for all others next week. We also made some bug fixes associated
with this, but it's slowly but surely wrapping up as a project for E3.
For *guided tours*, we've updated the feature so that if the tooltip is not
in your view, it has an animated scrolling action that takes you to it. For
example: for the majority of editors, they couldn't see the tooltips
pointing to preview and save on the edit form, because it was out of view
at the bottom in most browser sizes.
This is being used now as part of the getting started tour, but is
available to use for all tours, and we're debating whether to turn it on by
default. Any input from folks creating other tours would be welcome.
For *getting started*, we've just wrapped up A/B testing a new landing page
and a navigation bar on articles. It looks like it managed to double the
number of users accepting one of three getting started tasks, and we saw
our biggest increase in editors making their first edit so far, compared
the control that got no Getting Started page.
More at: https://meta.wikimedia.org/wiki/Research:OB5, and the interface is
now live for all English Wikipedians, if you want to visit
Special:GettingStarted and give it a spin.
--
Steven Walling
https://wikimediafoundation.org/
1. http://lists.wikimedia.org/pipermail/wikimedia-l/2013-May/126214.html
Hi folks,
We just deployed a new version of Notifications (formerly called 'Echo') on MediaWiki.org.
Today's main new feature is 'bundling' [1] , which only sends a single notification about related events, to reduce information overload.
For example, if several users post messages on your talk page in a row, you only get one web notification: "Kaldari and 2 others posted on your talk page."
To test this feature, check out section 6 of this testing page:
http://www.mediawiki.org/wiki/Echo/Testing
We've also started collecting our first metrics [2], tracking notifications events on this preliminary dashboard:
http://toolserver.org/~dartar/echo/
More features coming soon. Our next deployment will be Tuesday morning.
Thanks to Benny, Dario and Kaldari for making these new features possible!
Enjoy,
Fabrice
[1] http://www.mediawiki.org/wiki/Echo/Feature_requirements#Bundling
[2] http://www.mediawiki.org/wiki/Echo/Metrics
_______________________________
Fabrice Florin
Product Manager, Editor Engagement
Wikimedia Foundation
See below for a note from David Cuenca, whom I met at the Hackathon. He is
looking for design and product feedback from EE folk about a feature he
would like to implement.
---------- Forwarded message ----------
From: David Cuenca <dacuetu(a)gmail.com>
Hey Ori,
Thanks for your time during the Hackathon for checking out the additional
content card that Pau Giner suggested for making Wikimedia content from
sister projects more visible
https://meta.wikimedia.org/wiki/File:Inte-project_card_mockup.png
On the RFC nobody complained about it, more on the contrary it was a very
liked option. Unfortunately it came late when the surge of commenters had
already left, but I can well imagine that it will gather more positive
feedback when presented again.
https://meta.wikimedia.org/wiki/Requests_for_comment/Interproject_links_int…
Which relates to: https://bugzilla.wikimedia.org/show_bug.cgi?id=708
Thomas (User:Tpt) has begun to implement this mockup. To ckeck it out, add
this line to your common.js in Wikipedia
mw.loader.load('//
www.wikidata.org/w/index.php?title=User:Tpt/interproject.js&action=raw&ctyp…'
);
It will show a "+" sign next to the article title. When hovering the mouse
over the symbol, it will display Wikidata information. On this first
version it only displays basic info, but in the future it could display
Wikisource, Wikivoyage, Wikiquotes, etc. content or links.
I would need some guidance with two things, the first one is about
selecting the right icon... maybe you guys have some ideas about how to
make this "+" more likeable, maybe even replacing it for some different
icon?
And the second one is more regarding product management, do you have some
standard procedure about how to proceed?
I can imagine that creating a RFC would be the first step (done), and maybe
writing a blog post about it (doable), what would come next after that and
what would be a realistic time frame?
Hopefully you or your colleague Steven Walling could give some advice.
Cheers,
David Cuenca --Micru
PS:Feel free to forward this message to the EE mailing list.
Hi EE people,
Something that I'd find very useful is receiving a notification when someone has posted in a specific section of a page, particularly for talk pages. On busy policy talk pages it's a pain to use watchlists to determine if anything new has been said in a section that I care about. Watchlisting a page may tell me that there have been 30 edits today on that page but it doesn't tell me quickly if someone replied in a specific discussion that I want to watch. I tried to figure out if Flow will address this but it looks like Flow is mostly about user talk pages. In the future will Echo, Flow, or an improved watchlist system give a user a more visible notification when there's an edit to a chosen section or subsection on any page?
Thanks,
Pine
Hi folks,
For those of you going to Wikimania 2013 in Hong Kong this August, here are some of the editor engagement and product sessions submitted by our team so far.
If you're interested in attending any of these sessions, please sign your name at the bottom of the submission pages, to help reviewers decide which sessions are of high interest.
We'd also be grateful for your feedback about these proposals, so we can make any final edits before tomorrow's submission deadline.
Also, has anyone else submitted other editor engagement sessions that you'd like to share with this group?
Thanks to everyone who helped prepare these submissions. I look forward to some great sessions and more productive interactions at this year's Wikimania!
To be continued,
Fabrice
P.S.: This year, we are experimenting with a new 'roundtable' format: these creative workshops will invite community members to review and brainstorm feature ideas on topics like messaging and multimedia, in a highly collaborative 70 min. session that combines guided discussions with hands-on concept development, to help inform our product plans. Stay tuned for more on that front ...
_____________________________________________________
WIKIMANIA 2013 EDITOR ENGAGEMENT & PRODUCT SESSIONS
Engaging users on Wikipedia
Presentation by Fabrice Florin - 25 mins.
Track: WikiCulture and Community
https://wikimania2013.wikimedia.org/wiki/Submissions/Engaging_users_on_Wiki…
Notifications: A new editor engagement tool
Presentation by Fabrice Florin and Ryan Kaldari - 25 mins.
Track: Technology and Infrastructure (see also more technical session below, aimed at developers)
https://wikimania2013.wikimedia.org/wiki/Submissions/Notifications
How to enhance your MediaWiki extensions with Echo notifications
Presentation by Ryan Kaldari and Benny Situ - 25 mins.
Track: Technology and Infrastructure (see also overview session above, aimed at a general audience)
https://wikimania2013.wikimedia.org/wiki/Submissions/How_to_enhance_your_Me…
Article Feedback: New forms of collaboration between readers and editors
Presentation by Fabrice Florin, Pau Giner and Oliver Keyes - 25 mins.
Track: Technology and Infrastructure
https://wikimania2013.wikimedia.org/wiki/Submissions/Article_Feedback
Roundtable on Messaging and Discussions
Workshop by Fabrice Florin, Brandon Harris and others - 70 mins.
Track: Technology and Infrastructure
https://wikimania2013.wikimedia.org/wiki/Submissions/Roundtable_on_Messagin…
Roundtable on Multimedia
Workshop by Fabrice Florin, Rob Lanphier, Ryan Kaldari and Andrew Lih - 70 mins.
Track: Technology and Infrastructure
https://wikimania2013.wikimedia.org/wiki/Submissions/Multimedia_Roundtable
Technology Disruption and How We Organize for the Future
Presentation by Howie Fung - 25 mins.
Track: WikiCulture and Community
http://wikimania2013.wikimedia.org/wiki/Submissions/Britannica_to_Wikipedia…
Wikipedia Mobile, the Trojan Horse: Why MediaWiki has a separate mobile site
Presentation by Maryana Pinchuk and Jon Robson - 25-50mins.
Track: Technology and Infrastructure
https://wikimania2013.wikimedia.org/wiki/Submissions/Wikipedia_Mobile_The_T…
Wikimedia Software Translation Sprint
Workshop by Siebrand Mazeland - 70 mins.
Track: WikiCulture and Community
https://wikimania2013.wikimedia.org/wiki/Submissions/Wikimedia_software_tra…
The UserMetrics API: Measuring participation in Wikimedia projects
Presentation by Dario Taraborelli and Ryan Faulkner - 25 mins.
Track: Technology and Infrastructure
https://wikimania2013.wikimedia.org/wiki/Submissions/The_UserMetrics_API:_M…
Read more about Wikimania 2013 Submissions:
https://wikimania2013.wikimedia.org/wiki/Submissions
_______________________________
Fabrice Florin
Product Manager, Editor Engagement
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
My thinking with E2 is that they want to move to train deployments (biweekly or weekly) in any case. Though for Echo, that's not likely at the moment, so this is something to consider when things settle down, so this is something to consider after the first Flow extension gets released.
I believe they already do ride the train for most patches on existing projects in maintenance mode.
On May 16, 2013, at 1:24 PM, Greg Grossmeier <greg(a)wikimedia.org> wrote:
> I just want to highlight a question I have for the various feature teams
> at WMF:
>
> (Staying on engineering@ so that everyone can participate, instead of
> mailing individual team leads/etc.)
>
> <quote name="Greg Grossmeier" date="2013-05-14" time="15:15:10 -0700">
>> == Riding the Train ==
>>
>> Now is the time to start getting more development teams to start riding
>> the MW Core deploy train. If a one-week cycle/14 day lifespan (with the
>> always possible important backports available) is something doable for
>> your team right now, please do let me know. If it isn't, please let me
>> know what would be "good enough".
>
> Thanks!
>
> Greg
>
> --
> | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
>
> _______________________________________________
> Engineering mailing list
> Engineering(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
[Please CC me as I'm not subscribed to this mailing list]
Hi,
out of interest, which specific features or workflows are missing and
make the existing instances of Bugzilla / Mingle / Trello insufficient,
and are your usecases described in public somewhere? Do the evaluation
criteria in http://www.mediawiki.org/wiki/Tracker/PM_tool still apply,
or could that page be updated?
How to make sure that Flow feedback from users ends up in the correct
place? Thinking of Flow reports potentially filed in Bugzilla, is there
anything to move from or sync tickets between Bugzilla with Redmine?
andre
---------- Forwarded message ----------
> From: Dan Andreescu <dandreescu(a)wikimedia.org>
> Date: Wed, May 15, 2013 at 8:21 PM
> Subject: Re: [EE] Mingle for Flow
> To: Matthew Flaschen <mflaschen(a)wikimedia.org>
> Cc: WMF Editor Engagement List <ee(a)lists.wikimedia.org>
>
>
> Redmine's a pain to install but pretty great once up. It has a very
> good plugin model through which we can add anything we need. Rob
> Lanphier and I discussed this a few times and came to the conclusion
> that Redmine + helping upstream fixes to plugins like
> http://www.redminebacklogs.net/ should cover all our use cases. We
> even have a migration path from Bugzilla as we can import all the
> historical data, even preserving bug numbers:
> https://github.com/ralli/bz2redmine
>
> So if anyone decides to tackle this beast, count me in. The test
> redmine instance is back up (I think it goes down when the machine
> restarts - this is just my configuration mistake surely)
>
> http://redmine.instance-proxy.wmflabs.org/redmine
>
>
> On Wed, May 15, 2013 at 6:39 PM, Matthew Flaschen
> <mflaschen(a)wikimedia.org> wrote:
> >
> > On 05/15/2013 06:36 PM, Terry Chay wrote:
> > >> I agree these tools are problematic for this reason. I understand why
> > >> some people currently choose to use them, but the Foundation should
> > >> investigate free alternatives that can meet our projects' needs.
> > >
> > > I don't want to vary from Mingle or Trello until it's proven for current
> > > projects, but you and Mark Holmquist have some incentive to try out
> > > alternative tools. We could probably start a labs instance and come up
> > > with a project that is defunct or not under active development yet that
> > > we can try out using a tool of your choosing. :-)
> > >
> > > You guys have my okay to do that for something. :-)
> >
> > Dan Andreescu and I (mostly him) actually setup (a while back) a Redmine
> > instance for this purpose (with the goal of prototyping a nice FOSS
> > solution). It seems to be currently down, but it's at
> > http://redmine.instance-proxy.wmflabs.org/redmine/login .
> >
> > Matt Flaschen
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Begin forwarded message:
> From: Greg Grossmeier <greg(a)wikimedia.org>
> Subject: Re: [Engineering] One Week Deploy Cycle Recommendation
> Date: May 16, 2013 1:24:33 PM PDT
> To: Development and Operations engineers <engineering(a)lists.wikimedia.org>
>
> I just want to highlight a question I have for the various feature teams
> at WMF:
>
> (Staying on engineering@ so that everyone can participate, instead of
> mailing individual team leads/etc.)
>
> <quote name="Greg Grossmeier" date="2013-05-14" time="15:15:10 -0700">
>> == Riding the Train ==
>>
>> Now is the time to start getting more development teams to start riding
>> the MW Core deploy train. If a one-week cycle/14 day lifespan (with the
>> always possible important backports available) is something doable for
>> your team right now, please do let me know. If it isn't, please let me
>> know what would be "good enough".
>
> Thanks!
>
> Greg
>
> --
> | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
> | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
>
> _______________________________________________
> Engineering mailing list
> Engineering(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
(Switching it to the ee-list)
On May 15, 2013, at 1:32 PM, Fabrice Florin <fflorin(a)wikimedia.org> wrote:
> We may even want to try using it for remaining Echo tasks as well, not just for Flow.
I'm against changing things mid-stream. Let's see if Mingle works out for Flow (which hasn't started), and then we can see about its use elsewhere. Trello has worked out very well for E3 (as well as being valuable for the early development of Echo), and I'm not mandating E2 be backporting its use to Page Curation. ;-)
At the end of the day tools like Mingle, Bugzilla, Trello, Gerrit, wiki… are secondary documentation. Primary documentation is the code (git), followed closely by on-wiki for people who don't speak the language of code (when you think about it, that is part of our vision statement).
There is a cost to using secondary documentation, that means it has no value for its own sake, but only derives its value to the extent it helps in the creation of the primary forms.
Once a project has reached a certain level of maturity, any unnecessary documentation can be disposed of. Our process as it stands today doesn't allow us to be free of things like Gerrit, Bugzilla or wiki, but being able to let go of the unnecessary should be our goal. I like to think of these tools like writing on a napkin, it's okay at a certain time in the development process, but I wouldn't want everything we do to require a napkin doodling before implementation. ;-)
In the case of Mingle/Trello specifically these are closed source (possibly externally-hosted) software infrastructure pieces that we, as a Foundation, do not want to have an ongoing dependence on. During project creation and early development, the deadline-formation and other management tasks these afford are sometimes necessary in commercial space but do not really exist in all-volunteer open-source efforts, so some degree of dependence when there aren't open-source solutions becomes a necessary evil for that time in our project development. However, an ongoing dependence on these tools would become a wall prohibiting certain members of our community from being able to fully participate in, and that would be contrary to our commitment.
Take care,
terry
