--------------------------------------------
El mié, 16/11/16, Quim Gil <qgil(a)wikimedia.org> escribió:
Asunto: [Wikitech-l] Handling Phabricator notifications
Para: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org>
Fecha: miércoles, 16 de noviembre, 2016 05:32
Hi, it seems that there is many
people struggling with following
Phabricator notifications. Being overwhelmed by
notifications defeats the
purpose of notifications. :)
This is an invitation to share some thoughts.
The main trick is of course to pay attention to what you
subscribe/unsubscribe to. Sometimes I ask myself: why am I
receiving this
notification, and after a quick investigation it turns out
that I am still
watching some project that I am not really interested
anymore, or at least
not at the extent that it would impede me to follow better
the projects
that I really want to follow.
I actually unsubscribe from many tasks, and that keeps the
signal high vs
noise ratio high.
Email preferences can also help a lot reducing the amount of
(what for you
constitutes) noise. Also, many people seem to struggle with
volume of
emails received and haven't really tried the alternative of
web
notifications, which (at least for me) allow for quicker
scanning + the
fabulous button "Mark all as read".
I also set many types of notifications to "ignore", because
for me at least
the information they bring doesn't compensate for the noise
they create. I
have copied my Maniphest email preferences at
https://www.mediawiki.org/wiki/User:Qgil-WMF/Sandbox
just in case someone
finds them useful.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi all!
Tomorrow at the ArchoCom-RFC meeting [E367], we will go through the RFC board
[archcom-rfc] and try to reduce our backlog, assign shepherds, and come up with
a queue of topics to discuss over the next weeks and months.
If there are any RFCs that you would like to promote, please join!
The meeting will be at the usual time (Wednesday 21 UTC, 14 PST, 23 CET)
and place (#wikimedia-office). For an overview of ArchCOm activity, see
[ArchComStatus].
-- Daniel
[E367]: <https://phabricator.wikimedia.org/E367>
[archcom-rfc]: <https://phabricator.wikimedia.org/tag/archcom-rfc/>
[ArchComStatus]: <https://www.mediawiki.org/wiki/ArchComStatus>
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.
Hi all,
At November 16th - 18th Microsoft hosts Connect - Developer virtual event.
This event is streamed live and it's for free.
Link to event: https://connectevent.microsoft.com/
Speakers will share latest innovations from Microsoft software. There will
be many interactive Q&A sessions with Microsoft engineering teams,
customers and partners. Third day is an online full-day courses on
developing and deploying web and data applications or cross-platform mobile
apps.
Piotr
Source & feedback: https://www.mediawiki.org/wiki/Topic:Tfe8pv9zyrrlyb6d
This is a call to everyone interested in the Wikimedia Developer Summit
2017 -- including remote participants. We need you to help us decide which
sessions should be pre-scheduled in advance, getting bigger rooms, video
recording, and higher quality requirements.
Today we have 46 sessions competing for 15 slots. We need to propose a
schedule by December 12. How can you help?
The best way is to check the proposals submitted
<https://phabricator.wikimedia.org/project/board/2205/> and join those that
interest you in a visible way:
- participating in the discussion (the best way to prove your interest
and support the proposal)
- subscribing to the Phabricator task (click "Subscribe")
- awarding a token to the Phabricator task (click "Award Token")
The sooner, the better. We will start checking participation by November 28
(see the timeline
<https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Call_for_par…>
).
To be clear, this is not a popularity contest. Proposals with more
participation will be more likely to be pre-scheduled and vice versa.
However, the scheduling will be handled by the Program committee
<https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Program_comm…>.
They will take into account participation numbers, but they will also
consider other factors.
Proposals not scheduled will be directed to the Unconference
<https://www.mediawiki.org/w/index.php?title=Wikimedia_Developer_Summit/Unco…>
that
will run in parallel to the pre-scheduled sessions.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
I've posted an RFC at ...
https://meta.wikimedia.org/wiki/Requests_for_comment/Switch_default_categor…
... proposing that we change the default collation for Wikimedia wikis from
"uppercase" to "uca-default-u-kn" (Unicode Collation Algorithm with numeric
sorting). Please join the discussion if you have any thoughts on this.
On Tuesday Nov 13, at 9 am UTC, the web server for the dumps and other
datasets will
be unavailable due to maintenance. This should take no longer than 10
minutes. Thanks for your understanding.
Ariel
Hi,
YuviPanda, prtksxna, and myself (with help from Tim and Aaron) have been
working the UrlShortener extension, which is designed to implement the
URL shortener RfC[1] (specifically Tim's implementation suggestion).
I've filed T108557[2] to deploy the extension to Wikimedia wikis. We'd
like to use the "w.wiki" short domain, which the WMF is already in
control of.
A test wiki has been set up mimicking what Wikimedia's configuration
would be like: http://urlshortener.wmflabs.org/, and has an accompanying
"short" domain at us.wmflabs.org (e.g. http://us.wmflabs.org/3). Please
play with it and report any bugs you might find :)
[1] https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener
[2] https://phabricator.wikimedia.org/T108557
Thanks,
-- Legoktm
Hi,
bawolff wrote:
I actually disagree somewhat - I think it can be very rewarding to fix
> a problem that you yourself have, as opposed to fixing somebody else's
> problem. This is a traditional ideology about open source - that it is
> all about scratching your own itch.
> Although arguably most gsoc students coming up with their own projects
> aren't actually scratching their own itch but desperately trying to
> come up with an idea. However, if someone happens to be a preexisting
> user of MediaWiki, and finds something they find super annoying, I
> think that can make for a very good project.
In theory this is true. In practice, I'm not sure if there has ever been a
successful WMF GSoC project where the idea was the student's own - other
than in cases where the student was already part of the MediaWiki
community. Which makes sense: if a student's only experience with MediaWiki
is, say, reading and writing wiki articles, then chances are good that
whatever they find annoying is something that many other people also find
annoying, and thus would have been fixed already if it were easy to fix.
bawolff also wrote:
As for users sticking around - I think the communication around gsoc
> has shifted from "Here's some money so you can work on MediaWiki
> without starving to death" to "Here's a little money and a job so you
> can put something cool on your resume". If students are being
> attracted to the program principally to have something on their resume
> or for the money (To be clear, I'm not saying there is anything wrong
> with that), its not surprising that they leave afterwards when the
> money goes away. If we want to attract people in the long term, we
> should probably come up with a better carrot.
Yes, this is absolutely the issue. I don't know if there's a lower
"conversion" percentage now than there used to be, but certainly to
convince people to do free labor for you, especially if their first
experience with you involved payment, seems difficult. That's assuming that
free labor is the ultimate goal, as opposed to, say, finding more people
for the WMF to hire. More on that below.
Tony Thomas wrote:
I would want to agree to disagree at places like - 'hiring everyone of
> them' or things like that. If we are talking about making people stick,
> the model I am talking about would be a *cheaper *option ?
I assume that's a reference to what I wrote, although I certainly didn't
say to hire everyone - I said "students who had useful projects". I don't
know which option would be cheaper - hiring some of the students or setting
up a new mentorship program - but the main question is really what the goal
is. Is it to get more free labor over the long term? If so, I don't know if
either option is that effective. Personally, I think it's great if such
projects result in actually useful software, and it's a shame if that
software goes uncompleted or abandoned at the end of the program.
-Yaron
--
WikiWorks · MediaWiki Consulting · http://wikiworks.com