Conversation has been taking place on CodeReview about whether people
(developer and system administrators) will find it confusing that
there's code in both "extensions/Vector" and "skins/vector" that are
related but not the same thing.
I personally find it simple to understand and don't expect most
developers and system administrators to feel otherwise, but in the
interest of upholding the community-driven decision making process that
has made MediaWiki what it is, I wanted to bring a little extra
attention to the matter so we can make a decision and move on with our
lives.
I'm interested in views on whether the Vector extension should be named
something else or remain as it is. If your view is that it should be
renamed, suggestions for what it should be named would be useful.
Apologies in advance for the sheer triviality of this matter;
unfortunately these kinds of bike shed problems [2] tend to be
infinitely exciting, while complex matters are more often met with
general disinterest.
- Trevor
[1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/73030#c10054
[2] http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality
Offhand I hadn't even realized there were still chunks of Vector in an
extension since it got merged in as a skin! :)
More than the naming issue, it's important IMO to make sure that units that
belong together ship together and get enabled together. That definitely ties
in with the concerns about support burden.
Merging the ext bits to core makes sense on that basis, since the skin
itself is in core. The bits in the ext seem reasonably self-contained and I
don't think it would be much of a code review burden.
However I am sympathetic to the idea of keeping Vector-specific goodies
together as their own module. For future versions it might be beneficial to
bundle things like this together as standalone plugins that include both the
skin and the other code; if the infrastructure for bundling extensions with
the default install gets in, this can be a good way to modularize and can
reduce the work of merging things to *core* when we really just want to
*ship* them.
-- brion
Sent from my iPhone
Begin forwarded message:
> From: Mattias 'Tias' Guns <mguns(a)fosdem.org>
> Date: 13 oktober 2010 14:53:59 GMT+02:00
> To: Fosdem Announce <fosdem(a)lists.fosdem.org>
> Subject: [FOSDEM] Call for devrooms closing
> Reply-To: FOSDEM visitors <fosdem(a)lists.fosdem.org>
>
> We would like to inform all interested parties that the call for devrooms is running at its end.
>
> Coming Saturday, 16 October at 23.59 the call for devrooms closes.
>
> Until then, proposals for organizing a devroom can be submitted on http://fosdem.org/call_for_devrooms.
> We welcome, and will favor, proposals involving multiple, collaborating projects.
>
> Acceptance notification will be sent out and announced here around the 23th of October.
>
>
> The FOSDEM staff.
> _______________________________________________
> FOSDEM mailing list
> FOSDEM(a)lists.fosdem.org
> http://lists.fosdem.org/mailman/listinfo/fosdem
Hi,
These days I had a little time to clear my TODO list after Wikimania
and I tried to find some information about the "central interwiki
repository" idea. While it was fairly trivial to find info about the
proposal itself [0] and the technical details proposed by Nikola
Smolenski, it was not so easy as to discern the current status of the
proposal.
What I want to know is:
1. Is there support from the community for some extended tests on this
subject on the Wikimedia websites?
2. Are there plans to extend the current extensions in order to
support something like [1], which would be much more interesting, but
also much more challenging?
3. Perhaps there are alternate proposals which target the same problem?
Thanks,
Strainu
[0] http://strategy.wikimedia.org/wiki/Proposal:A_central_wiki_for_interlanguag…
[1] http://strategy.wikimedia.org/wiki/Proposal:A_central_repository_of_all_lan…
All,
Over the past week or so, Roan, Brion and I have been getting CodeReview
reviewed. We've just updated deployment from trunk, and I'd like to point
out a few major things (plus of a bunch of other fixes, of course):
* Statistics on code review, specifically the "wall of shame" for fixmes[0]
* A new 'old' status for revisions, basically for anything that is 2+ years
old and still unreviewed[1]
* Broken parser tests results system was removed, we've been using
phpUnderControl for a little while now and it's a little more reliable :) [2]
Try things out and let us know if you see any (more) breakages.
-Chad
[0] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/stats
[1] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/status/old
[2] http://ci.tesla.usability.wikimedia.org/cruisecontrol/buildresults/mw
Hi everyone,
I'd like to make everyone aware of this new open position:
http://wikimediafoundation.org/wiki/Job_openings/Bugmeister
The goal for the person hired to this position is to sift through the many,
many bugs we have in Bugzilla, and surface the ones that are most important
for everyone to focus on.
We're looking for someone who understands our editing community and
developer community, and isn't intimidated by Bugzilla or its trappings.
However, we're *not* looking for someone with 10+ years of development
experience.
We think this is a really good entry-level position for someone who is eager
to work with Wikimedia Foundation and is interested in the technical
problems, but isn't (yet) suited to be a developer or other more technical
role. This position represents a great opportunity for someone interested
in learning the ropes here. That said, we want to make sure we hire someone
who is going to stick with it for a little while, rather than get bored
after a month or two and wander off to do something else.
We imagine this person is going to be responsible for running community
triage discussions, updating fields in Bugzilla, helping update our bug
filing documentation, and helping members from our editing community file
quality bug reports. We want someone who really wants to do a fantastic job
with this for a year or two before moving on to other roles.
If you're interested, please apply! (and let me know that you did) If
you're someone who hangs around on this mailing list, IRC, etc, please make
sure to point that out in your cover letter, along with the id you use
around these parts.
Rob
Hello,
We have two new committers joining the crowd:
Erik Zachte - ezachte - Working on Wikistats scripts
Diederik van Liere- diederik - Contractor working on data dump analysis.
Welcome aboard!
-Chad
Hi,folks,
recently, I developed a toolset to help people effectively observe changes
on Wikipedia.
It include below function points:
* filter recentchanges to get recent article changes on specific categories
* filter recentchanges to get recent discussions on specific categories
* notify the user when new content added to a talk page which the user had
contribute to
* a shorturl service
With open json api, these function point had already been implemented via
Wikipedia User Script.
This means Ultrafilter toolset can be integrated with Wikipedia seamlessly.
The main ideas behind the tools are:
* Effectively observable for Wikipedia users
* Effectively observable for outside world with RSS output(to be
implemented)
* Better communication inside Wikipedia
To prove the concept, I had setup a node to serve Chinese Wikipedia
community.
If it is popular in Chinese Wikipedia and the fees for server nodes could be
covered in a reasonable way,
I would like to setup more nodes for other languages.
This toolset is only a two-weeks' work, and is based on Node.js.
Since Node.js is pretty new, I take this project just as an experiment for
above concepts and Node.js itself.
You can visit http://ultrafilter.org to take experiment, but only Chinese
version have the full features.
If you are interested with this toolset, you can contact me seperately in
another mail.
Thanks.
Regards,
Mingli (User:Mountain)
Hi everyone,
A few of us (Brandon, Alolita, and I) had a conversation about
clearing up the more vague items on the Pending Changes roadmap
(http://www.mediawiki.org/wiki/Pending_Changes_enwiki_trial/Roadmap ),
and we'd like to get some further feedback on what we discussed.
First, the priority that we're tackling the vague stuff:
1. 25299: Make pending revision status clearer when viewing page:
https://bugzilla.wikimedia.org/show_bug.cgi?id=25299
2. 25295: Improve reviewer experience when multiple simultaneous
users review Pending Changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=25295
3. 25296: History style cleanup - investigate possible fixes and
detail the fixes
https://bugzilla.wikimedia.org/show_bug.cgi?id=25296
4. 25301: Firm up the list of minor UI improvements for the November
2010 Pending Changes release
https://bugzilla.wikimedia.org/show_bug.cgi?id=25301
5. 25298: Figure out what (if any) new Pending Changes links there
should be in the side bar
https://bugzilla.wikimedia.org/show_bug.cgi?id=25298
(Note that there are other tasks that Chad and Priyanka are already
tackling that aren't on this list.)
Now for some more detail on each:
================================================
1. 25299: Make pending revision status clearer when viewing page:
https://bugzilla.wikimedia.org/show_bug.cgi?id=25299
Right now, it takes a sharp eye to notice when one is looking at a
page that hasn't been accepted yet. The main visual indicators are an
icon on the right, and the fact that the "Pending Changes" rather than
the "Read" tab is highlighted. What we plan to do here will be
modeled on what you see when you're looking at an old revision (i.e.
there will be a horizontal notice at the top indicating "This is an
pending revision of this page, as edited by 127.0.0.1 (talk |
contribs) at 13:37, 7 October 2010. It may differ significantly from
the accepted revision.")
An old decision that we plan to revisit: currently, the revision you
are shown depends on whether you're logged in or not you are logged
in. If you're not logged in, then by default, you see the accepted
revision. If you are logged in, you see the pending revision by
default. Brandon feels pretty strongly that we need to be much more
consistant here, always showing the accepted revision regardless of
logged-in status. There's some research we need to do to make sure we
understand the current rationale, but barring any unexpected insight,
we'll probably be making the switch.
================================================
2. 25295: Improve reviewer experience when multiple simultaneous
users review Pending Changes
https://bugzilla.wikimedia.org/show_bug.cgi?id=25295
Here are some of Brandon's initial thoughts.
* We only want to show that a page is "under review" to other
reviewers of the page.
* We want to show who is reviewing the page, but also only to other
reviewers of the page.
* We should include better colors/icon.
Almost everyone who I've talked to about this problem feels like maybe
the timeout needs to be tuned, but since almost no one knows what the
timeout is, that may be the problem itself.
One possible workflow (inspired by our conversation, but not vetted by
Brandon or Alolita) is this:
* On the list of pages to review, keep the "under review" notice
pretty much exactly as is
* On the review page, in the "Review this revision" box, put one of
two notices:
** "This page is being reviewed by User:Xyz, who started 20:09, 7 October 2010"
** "You are being advertised as currently reviewing of this page
(started 20:09, 7 October 2010). [Stop reviewing]"
This would add some transparency to the review process, which will
help us tune the timeout and generally make this work more as people
would expect it to.
Some implementation questions that we didn't know the answers to:
1) Do we know *who* is doing the reviewing of a page? (i.e. is this
already stored somewhere we can get at it easily) If so, the notice
should be pretty straightforward.
2) If so, when *anyone* looks at a set of pending changes, does it
mark it as "under review"? We're assuming not, but one thing that's
frustrating is that any time a reviewer looks at a diff, that
automatically puts the page "under review".
================================================
3. 25296: History style cleanup - investigate possible fixes and
detail the fixes
https://bugzilla.wikimedia.org/show_bug.cgi?id=25296
This one represents a bit of a paradox for us. On one hand, we know
that there is a LOT of work to do here, and thus, we know that we're
not going to make significant usability progress on this one by
November. On the other hand, there are a number of little things that
are annoyingly wrong, and with just a small amount of care and
attention, we could make incremental progress on.
We don't want to allow the perfect to be the enemy of the good, so
we're going to try to restrain ourselves, and come up with a few easy
things that we can do to make this a little bit better. Brandon is
planning to spend some time looking at the history page and come up
with some formatting and wording fixes that will make the Pending
Changes history pages a little better.
================================================
4. 25301: Firm up the list of minor UI improvements for the November
2010 Pending Changes release
https://bugzilla.wikimedia.org/show_bug.cgi?id=25301
This is actually a task for sorting through a small list of seemingly
easy things. Many of the items here are probably within the grasp of
an interested admin to just fix rather than waiting on us for.
Brandon is planning to sweep through on all of these and come up with
a few specific recommendations. If you have some thoughts, we'd
appreciate them here.
------------------------
4a. Better links to documentation on PC related specialpages - from
the comments: "The review page could have links to Help documentation,
reviewer guidelines, and PC policy pages."
------------------------
4b. Incorporate the PC protection rationale (protection log message)
into the review screen as instruction to the reviewer - from the
comments: "Make the protection rationale visible (currently it's
click-to-expand). That way Reviewers could see up front if PC was in
use for Vandalism, BLP, edit warring, etc. Helps alert them to the
'type' of problematic edits, particularly more subtle kinds."
------------------------
4c. Add short reviewer instructions to the review page - from the comments: "
Just a summary of how to review. Depends on policy discussions about
reverting vandalism or also poor edits. Currently could just include
the reviewer guidelines writ small.
------------------------
4d. Quick link to Pending Changes specialpages - from the comments:
"Easy access from the sidebar, or other common locations (not sure
where)."
================================================
5. 25298: Figure out what (if any) new Pending Changes links there
should be in the side bar
https://bugzilla.wikimedia.org/show_bug.cgi?id=25298
We're probably not going to address this one in the November 2010
release. If we do it, we need to make it conditional upon whether the
person has reviewer rights. The problem with this one is that we
don't yet have clear guidelines for what belongs in the toolbox on the
left, and whether any of the pending changes special pages rise to the
level of importance that we should put them in the toolbox.
================================================
That's the list that we're looking at now. Let us know what you think.
Rob