Hi all,
you are cordially invited to the first ever IRC office hours of the
Foundation's recently formed Analytics team, taking place in
#wikimedia-analytics on Freenode on Monday, July 30 at 19:00 UTC /
noon PT (http://www.timeanddate.com/worldclock/fixedtime.html?hour=19&day=30&month=0…
).
It is an opportunity to ask all your analytics and statistics related
questions about Wikipedia and the other Wikimedia projects, in
particular regarding the Wikimedia Report Card and the upcoming
"Kraken" analytics platform. See also the blog post that the team just
published: https://blog.wikimedia.org/2012/07/25/meet-the-analytics-team/
, as well as https://www.mediawiki.org/wiki/Analytics
General information about IRC office hours is available at
https://meta.wikimedia.org/wiki/IRC_office_hours .
Regards,
--
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB
Hi all,
The lead author of Oauth 2.0, Eran Hammer, has withdrawn his name from the
OAuth 2 spec:
http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
That's a very sad news, IMHO, and it probably means we really should
reconsider what protocol we want to support Oauth 1.0 / Oauth 2.0 / SAML or
something else if we want to allow interoperability with our sites.
Best,
Diederik
Hi,
In the last few months I was involved in a few editing workshops for
new users. When we told people to create user accounts, they often
chose usernames based on relatively common people's names, but it
usually didn't happen in wikis in major language like English or
Russian, so their username was accepted, as there were no other user
with the same name on the same wiki. But when they entered a wiki in
another major language, they had to create a new account with a
different name for the obvious reasons.
How hard would it be to auto-convert to SUL all the accounts with
names that exist only on one wiki, so it would appear like this name
is already taken? This should prevent such problems in the future.
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Hi.
Splitting off from the "serious alternative" thread, I wanted to make note
that the view that some hold about Gerrit being a developer-only tool is
probably completely wrong and may be contributing to some of the strains and
pains we've been seeing.
Much like Bugzilla (and MediaWiki, to be honest), Gerrit is serving (or
under-serving) multiple audiences. It is simply not just a developer tool,
as I've come to understand it, just as Bugzilla and MediaWiki's CodeReview
extension were not just developer tools. Community members are involved and
engaged in bug and feature filing in Bugzilla, which is directly linked with
Gerrit. When a bug is now marked as resolved, a developer will include a
direct link to a Gerrit changeset for the bug filer (and on-lookers) to see.
In on-wiki discussions, it was never uncommon for people to cite r1234,
which previously directed users to SVN's ViewVC and then subsequently
directed users to MediaWiki's CodeReview interface. Now we have people
citing gerrit change fads9f008 or whatever in on-wiki discussions.
We have direct and explicit exposure of Gerrit to non-developers.
I think this is a crucial point. It means that it's not only acceptable for
non-developers to be involved in discussions about Git front-ends, it's
essential that non-developers be involved.
I haven't seen much documentation of Gerrit for non-developers. I started a
page here: <https://www.mediawiki.org/wiki/Gerrit/Documentation> (though
it's already grown to be more developer-focused).
We need to think more about the "multiple audiences" problem and how to
properly address it.
MZMcBride
Hey,
After discussion with Robla and DanielK, we (the Wikidata team) decided to
write mails to this list now and then complain about our blockers for which
we need WMF (or other core dev) assistance :)
Right now we have three patches to core awaiting review:
* https://gerrit.wikimedia.org/r/#/c/14084/
Simple patch, which as far as I can tell is ready to go in. Development of
core parts of our phase one functionality is blocked by this, and not
having this merged is causing hassle for people that want to setup their
own working Wikidata repo-client install.
* https://gerrit.wikimedia.org/r/#/c/14295/
More complex patch, but has no effect on existing code in core yet, so can
be merged in without much risk. It's less urgent then the first patch,
although it just sitting there is causing overhead in regard to further
developing this code, and is preventing us from starting to work on
updating core code to make use of this rewrite.
* The Wikidata core branch with ContentHandler stuff
DanielK needs to chime in here, as I was unable to find anything sitting on
gerrit waiting for review. In any case, my understanding is that we still
need to get quite a bit merged in, doing this step by step, so obviously we
can only get to the next one when the current one got merged.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
Hi everyone,
We've wanted to change the Gerrit UI to be less ugly for quite awhile, and I
think a good first step is getting rid of the puke green/yellow color
schemes. Gerrit has the ability to change these colors without using CSS--
it's done with the "theme" configuration[0]. I'm awful at choosing these
sorts of things, so I thought I would open it up to the list for a bit of
bikeshedding to come up with some colors we can use.
Specifically, there's 5 colors we can change *right now* and that I'd love
to get some input on what to change them to. These 5 are:
1) backgroundColor -- pretty self explanatory, default is #FCFEEF for
anonymous users and #FFFFFF for logged in users.
2) topMenuColor -- the color in the top menu area, the puke green, #D4E9A9
3) textColor -- self explanatory, default is #000000
4) trimColor -- used for section headers and such, same green as
topMenuColor by default
5) selectionColor -- the cream-yellow color used when you're highlighting a
given field/button/etc in Gerrit, color is #FFFFCC
Additionally, there's 3 more colors that we'll be able to customize starting
with 2.5, so it's worth keeping them in mind (and maybe going ahead and
picking colors for them too):
5) changeTableOutdatedColor -- That glaring red that shows up in the
dependencies field when a dependency is outdated, default #F08080
6) tableOddRowColor -- with 2.5, we can do alternating colors for the change
listings, making it easier to read. By default, transparent.
7) tableEvenRowColor -- complement of above
We can test these all on the labs instance of Gerrit[1], and in fact RobLa
and I tried some colors awhile back (but neither of us are designers). If
anyone wants access to the instance so they can play with it, please ping
me and I'll be happy to add you. Thanks for input everyone :)
-Chad
[0] https://gerrit.wikimedia.org/r/Documentation/config-gerrit.html#_a_id_theme…
[1] http://gerrit-dev.wmflabs.org/
Are there any initiatives in the MediaWiki community for a MediaWiki
theme that supports 'responsive design' [1] -- where content is properly
laid out in an accessible form on all manner of devices including
desktops and smart phones?
[1] http://www.alistapart.com/articles/responsive-web-design/
From the start of the OAuth idea I've been thinking we should handle the
code in an abstract way.
ie: Applications and Authorizations should be something MediaWiki
implements internally in an abstract way. And then we write an OAuth
extension that extends this and lets you authorize OAuth 2 clients.
Things like mass-reverts by application, authorization revocation, and
displaying what application was responsible for an edit would be handled
from within MediaWiki abstractly instead of being OAuth specific.
-- Skip for TL;DR version --
Originally I had some ideas like implementing some custom auth system for
other wiki. Implementing OAuth 1.0 in addition to OAuth 2 (at the time it
appeared signatures had disappeared and OAuth 2 was worse than OAuth 1 in
some cases). And supporting something along the lines of Google's
application passwords.
I'm not focused on that right now. But I still think it would be a good
idea to do. We don't know what'll happen in the future. Someone could
write an OAuth 3 that is also not backwards compatible and we want to
implement. Or someone could come up with a different standard that does
things in a more secure way or supports discovery in a very well thought
out way. So doing things abstractly will let us add those as things go
along without any trouble.
Additionally doing this abstractly allows us to test just small components
of the system in an isolated way without needing a whole OAuth stack.
-- / continue reading from here --
I had an interesting thought when I was thinking about how we'd do this
abstractly.
- I started thinking that every user instance should have some sort of
->getApplication()/->getAuthorization() connection. And this would be used
when noting what was responsible for various edits/logs/etc...
- To make things easy on code I thought that ->getApplication() should
always return an Application instance so you don't have to null test it.
Under that idea MediaWiki itself would have a dummy Application which
would be tied to every standard edit. The database would probably even
reflect this.
After this I started thinking of separating things a bit more.
- By default every blandly created User instance would be tied to an
"Unknown" application.
- While when a user instance is setup using session data we assign the
"Internal" application to it.
- As a result of this all dummy edits made through internal code would end
up associated with an "Unknown" application instead of the "Internal" one.
In other words, we'd finally have a formal way to find system made edits
like the initial Main Page edit populated by the installer. That would be
an "Unknown" application. The same would go for various extensions that
made dummy edits.
- To top all this off we could potentially also make a special built-in
"Import" application. This would result in all edits made by importing
edits from another wiki being nicely annotated in the UI with information
saying they were imported rather than actually made on the wiki by said
person.
What does everyone think of this idea?
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On Thursday, July 26, 2012, Faidon Liambotis wrote:
> This is not to you specifically but as a general remark: there are
> multiple other alternatives that have been mentioned besides Gerrit and
> GitHub with a potential of getting the best of both worlds. I think it's
> better to not polarize the discussion between the two most popular
> options at this point and talk about all options.
Nice segue into a topic that I've been meaning to get to. :) Right now,
the serious alternatives seem to be:
* Sticking with Gerrit (with GitHub integration)
* Moving fully to GitHub
* Moving to Phabricator (though the proposal is pretty thin right now)
Nothing else has been advocated with a degree of seriousness as to warrant
consideration at this point. That's not to say we're done with those
options; if someone wants to put together a serious proposal, there's still
a little time. However, in order to practically consider the alternatives,
we need to have the serious proposals enumerated, and a credible plan for
addressing any deficiencies.
I've gone through and modified the criteria, splitting up the MUSTs from
the SHOULDs:
http://www.mediawiki.org/wiki/Git/Gerrit_evaluation
Even the "sticking with Gerrit" section is currently thin on credibly
meeting the criteria, so we'll have to beef up our stated plan for getting
it up-to-snuff.
Here's the timeline I'd like to propose:
* July 30, noon PDT - reasonably complete draft sections need to be in
place
* August 1, 9am PDT - complete proposals due
A few of us are planning to meet Monday afternoon to figure out exactly
what the rest of the process looks like, so that first deadline is going to
be very important for understanding how many options we're truly
considering.
Thanks
Rob