I just merged and deployed https://gerrit.wikimedia.org/r/#/c/184886/ ,
which means:
A +1 in gerrit.w.o didn't have any technical effect until now. Now it
submits the patch for testing. That means if you +1 a patch from a
non-whitelisted user that was not yet tested, it will then, just as if
recheck was issued. Thus executing the code that you reviewed to not
steal secrets or compromise security in other ways.
--
Regards,
Jan Zerebecki
Agree with everyone else, this is great!
I just have a question. Is this an evolving thing in a sense that more
data sources will be used to define page views? Let me give an example.
Reading Web team is working on a new web app prototype that caches pages
which can be viewed without hitting the back end. Since no request is
made, no page view will be recorded. We may add an event logging event to
record a page view which would be another source of information for this
API end point.
Baha
On Tue, 17 Nov 2015 02:50:20 +0500, Dan Andreescu
<dandreescu(a)wikimedia.org> wrote:
> Dear Data Enthusiasts,
>
>
> In collaboration with the Services team, the analytics team wishes to
> announce a public Pageview API
> <https://wikimedia.org/api/rest_v1/?doc#!/Pageviews_data/get_metrics_pagevie…>.
> For an example of what kind of UIs someone could build with it, check out
> this excellent demo <http://analytics.wmflabs.org/demo/pageview-api>
> (code)
> <https://gist.github.com/marcelrf/49738d14116fd547fe6d#file-article-comparis…>
> .
>
>
> The API can tell you how many times a wiki article or project is viewed
> over a certain period. You can break that down by views from web
> crawlers
> or humans, and by desktop, mobile site, or mobile app. And you can find
> the 1000 most viewed articles
> <https://wikimedia.org/api/rest_v1/metrics/pageviews/top/es.wikipedia/all-ac…>
> on any project, on any given day or month that we have data for. We
> currently have data back through October and we will be able to go back
> to
> May 2015 when the loading jobs are all done. For more information, take
> a
> look at the user docs
> <https://wikitech.wikimedia.org/wiki/Analytics/AQS/Pageview_API>.
>
>
> After many requests from the community, we were really happy to finally
> make this our top priority and get it done. Huge thanks to Gabriel,
> Marko,
> Petr, and Eric from Services, Alexandros and all of Ops really, Henrik
> for
> maintaining stats.grok, and, of course, the many community members who
> have
> been so patient with us all this time.
>
>
> The Research team’s Article Recommender tool
> <http://recommend.wmflabs.org/>
> already uses the API to rank pages and determine relative importance.
> Wiki
> Education Foundation’s dashboard <https://dashboard.wikiedu.org/> is
> going
> to be using it to count how many times an article has been viewed since a
> student edited it. And there are other grand plans for this data like
> “article finder”, which will find low-rated articles with a lot of
> pageviews; this can be used by editors looking for high-impact work.
> Join
> the fun, we’re happy to help get you started and listen to your ideas.
> Also, if you find bugs or want to suggest improvements, please create a
> task in Phabricator and tag it with #Analytics-Backlog
> <https://phabricator.wikimedia.org/tag/analytics-backlog/>.
>
>
> So what’s next? We can think of too many directions to go into, for
> pageview data and Wikimedia project data, in general. We need to work
> with
> you to make a great plan for the next few quarters. Please chime in here
> <https://phabricator.wikimedia.org/T112956> with your needs.
>
>
> Team Analytics
--
Baha
An example here:
https://he.wikipedia.org/wiki/%D7%92'%D7%95%D7%A0%D7%AA%D7%9F_%D7%A4%D7%A8%D7%99%D7%99%D7%A1?previous=yes
I couldn't find a description of the "previous" parameter. Does someone
know (and how do I find this out by myself)?
(I was looking here:
https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php but could not
find anything, so I assume this comes from some extension, but I do not
know how to figure that out)
Hey all,
Starting in January 2016, MediaWiki will end JavaScript support for
Microsoft Internet Explorer 8. This raises the cut-off up from MSIE 7.
Users with this browser will still be able to browse, edit, and otherwise
contribute to the site. However, some features will not be available to
them. For example, the enhanced edit toolbar will not appear, and the
notification buttons will take you to a page rather than a pop-out.
This change will affect roughly 0.89% of all traffic to Wikimedia wikis (as
of October 2015). For comparison, 0.33% of traffic comes from Internet
Explorer 6, and 1.46% from Internet Explorer 7. Support for these was
dropped in August and September 2014 respectively.
Providing JavaScript for IE 8 adds a significant maintenance burden. It
also bloats the software we ship to all users, without proportionate
benefit. This enables us to simplify and streamline the JavaScript codebase
for all other users. Users unable to upgrade from Internet Explorer 8 will
have a faster experience going forward, based on well-tested and more
stable code.
This change will land in the development branch in January, and so will be
part of MediaWiki 1.27 (to be released around May 2016).
Tech News will announce this change as well, but please help carry this
message into your communities. In January, we will send a reminder before
the change happens.
Yours,
-- Krinkle
For details about the JavaScript-less experience, see
https://www.mediawiki.org/wiki/Compatibility
Wikimedia is among the 14 organizations in Google Code-in (GCI) 2015!
In Dec & Jan, many young students will want to contribute to Wikimedia.
Will you mentor some tasks? It's easy and fun.
GCI is a great opportunity to let new contributors complete those small
little tasks on your To-Do list! Task areas are: Code, docs/training,
outreach/research, quality assurance, and user interface.
Do your docs on your wiki need some improvements?
Does your template or gadget code needs some updates?
Do you have small and self-contained bugs you'd love to get fixed?
Does your UI have small design issues?
Do your old bugs welcome some testing?
Then become a mentor and enjoy working with a contributor!
Add yourself to the mentor's table on the wiki page, get an invitation
email to register on the contest site, and create tasks (which would
take you 2-3h to complete, or less technical ~30min "beginner tasks")!
Explain the expectations and deliverables in the task. Once the contest
starts on Dec 07, be ready to answer and review contributions quickly.
See https://www.mediawiki.org/wiki/Google_Code-in_2015#Mentors.27_corner
Need task ideas? Check out the list of "easy" tasks in Phabricator:
https://www.mediawiki.org/wiki/Annoying_little_bugs
lists Phabricator queries for your area!
https://www.mediawiki.org/wiki/Google_Code-in_2015 has all information.
Or just ask and we'll be happy to help!
Thank you!
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Hi, this is an update on the work we in the Collaboration team are
doing. Our focus is on cross-wiki notifications and other back-end
improvements to that system.
Our long-term goals are to make various improvements to the Notification system.
Notifications are at the core of many different on-wiki activities.
Making notifications easy to find and use can help those processes. We
are focusing our immediate plans on supporting cross-wiki
notifications. These will help editors stay informed about the changes
they care about on every Wikimedia project on which they work. This is
especially important for the editors who work on more than one wiki.
Examples include if you upload to Commons, curate on Wikidata, or edit
in two or more languages.
The team has spent the last few weeks researching the existing and
proposed features. This has included examining existing tools such as
Crosswatch. We've been considering the problems of:
* technical performance (scaling the requests across 800+ wikis),
* user preferences (both existing and desired),
* user interface design possibilities (how it should work),
* how to release an initial, user-testable version for feedback and
improvement, and
* how to measure the impact of the project (reducing the time it takes
to process a notification).
We are also doing user research via 1-on-1 interviews. In these we ask
active editors about their current notification usage and pain-points.
Using a prototype we are evolving, we get feedback on directions to
take the design.
== Details and further reading ==
You can read more about the technical details at:
https://www.mediawiki.org/wiki/Requests_for_comment/Cross-wiki_notifications
.
Some of the new backend improvements to Echo:
https://phabricator.wikimedia.org/T107823 ("Rewrite
EchoNotificationFormatter") and linked tasks.
User preference options are:
* https://phabricator.wikimedia.org/T117670 ("Define Cross-wiki
Notifications settings")
User interface design possibilities cover several questions. For
example, how should cross-wiki notifications look within the pop-up?
How and when should we add enhancements to the Special:Notifications
page to filter things? We are drafting and discussing these in:
* https://phabricator.wikimedia.org/T114357 (Clarifications to the
currently confusing "primary/secondary" link, and proposed future
enhancements)
* https://phabricator.wikimedia.org/T114356 (Bundled notifications)
* https://phabricator.wikimedia.org/T115264 (Controlling notification
'volume' based on the type or location)
* https://phabricator.wikimedia.org/T115845 (Clearer use of the
notification badges (coloured number in personal toolbar))
* https://phabricator.wikimedia.org/T115316 (Better organization of
the Special:Notifications page)
Note: Most of these are not part of the cross-wiki notifications
feature. We won't for sure roll all these out together with the main
change.
We started user research at https://phabricator.wikimedia.org/T114086
and it continues at https://phabricator.wikimedia.org/T116741 . (Note:
You can sign-up as a volunteer at https://wikimedia.org/research .)
A user-testable release is still just in planning. We decided on a
Beta Feature on each wiki as the most scalable and least confusing of
all the do-able options. Read our plans in
https://phabricator.wikimedia.org/T114237 ("Present cross-wiki
notifications as a beta feature to users"). This will help users to
try the feature anytime, disabling it if it interferes with their work
in some context, and easily suggest how the tool could be improved.
There is no system for users having or setting cross-wiki preferences.
Waiting to building this would take a long time. For now, we plan to
let you enable the Beta Feature at each wiki on which you want to test
it. This will let you have a small-scale Beta Feature that you can all
try out. We will be able to discover bugs, edge-cases, iterate more,
and get even more feedback. Later, when we know what features you
need, we can build such a cross-wiki preferences system (including the
task linked above).
Whilst you wait, we would love to hear your feedback on the above.
What comments, what design ideas, and what technical concerns do you
have? Please tell us on the linked tasks if you can.
I'll send further updates, when the planned Beta Feature is about to be ready.
On behalf of the Collaboration team, thank you to everyone who has
given your help already.
--
Nick Wilson / Quiddity
Just noticed that Wikigenes has a couple of interesting tools. There's a
way for editors to highlight the contributions in an article that were made
by specific users, and also a way to rate edits on a scale of 0 to 4. I'm
unsure how valuable the scale would be in light of Aaron's ongoing work
about edit value and also in light of our "thanks" feature, but I'd like
the ability to highlight contributions on a page by individual authors. Is
there any possibility of bringing that tool over to Wikimedia sites?
Pine
Hello,
I would like to remind that I made this guide some time ago:
https://www.mediawiki.org/wiki/User:Petrb/Git_for_idiots
It always quite sucked and still does, but I tried to slightly rewrite
it now, so it should contain more accurate information.
I would like to keep it as a super simple manual / cheat sheet for
git, that is as much clear and simple as possible.
If you ever struggled with git, maybe it could help you. If you are a
git expert you may want to contribute to it? The name of the guide may
not be a best choice, so I might eventually move it to [[Git for
dummies]] or something like that, so that it sounds a bit more
friendly.
I don't know if we already have any super simple guide / cheat sheet
for git, where you could find everything essential on 1 page (and it
was a wiki page editable by everyone), but I think we don't. We might
use this as one?