On Thu, Jan 16, 2014 at 2:52 PM, Rob Lanphier <robla(a)wikimedia.org> wrote:
> Let's put that number at 95% :-) I don't want to commit the group to
> anything; it's at the top of the short list, but you never know where
> people will want to take the conversation.
>
> Legoktm, the thing you could do to push it over the top is to write up
> a summary as you see it of the various positions, and post it to this
> list. Ideally, you would also publish it as a subpage of the
> Architecture Summit 2014 page, similar to how some of the others are
> (e.g. HTML templating[1]) Even if we don't get to it at the summit,
> it still will be a very useful backgrounder to have. Is that
> something you'd be willing to chip in with?
Sure, I created
<https://www.mediawiki.org/wiki/Architecture_Summit_2014/Configuration>,
and solicited feedback from ^demon and Yurik. I've included it below
for ease:
MediaWiki is currently configured via a series of global variables
that must be set in a PHP file by a user with file system access. This
cluster of RfCs intends to allow the wiki to be configured using an
on-wiki mechanism. Some of the motivations behind this can be found in
the first RfC[1].
The first two RfCs, "Configuration database"[2], and "Configuration
database 2"[3] discuss storing configuration parameters in a database
table, while "Json Config pages in wiki"[4] discusses using a JSON
ContentHandler to store configuration options in a wiki page.
Some of these features have already been implemented in extensions:
Configure provides basic on-wiki configuration functionality, and
CentralAuth allows custom global user groups to be created on-wiki.
The EventLogging, UploadWizard, and ZeroRatedMobileAccess extensions
all currently store configuration options in JSON formatted pages.
See also: bug 26992[5], "Implement configuration database aka
configuration management aka no shell excuse (tracking)"
[1] https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database#…
[2] https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database
[3] https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database_2
[4] https://www.mediawiki.org/wiki/Requests_for_comment/Json_Config_pages_in_wi…
[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=26992
-- Legoktm
Aaron Schulz has become the first person to have approved (+2'ed) >=
1000 patchsets to mediawiki core [1]. I thought this nice round number
deserved a note, and a "good job". Thank you Aaron for all your hard
work reviewing things.
--bawolff
[1] https://toolserver.org/~nemobis/crstats/core.txt
Hi,
Here, its Nitin Agarwal, Software Developer and Programmer. I am currently
pursuing Computer Science and Engineering at International Institute of
Information Technology, INDIA.
I would like to Wikimedia as Web Developer and Systems Administrator
projects. I have gone through the
https://www.mediawiki.org/wiki/Starter_kitand installed and configured
mediawiki on my machine running at localhost.
I would like to work on the ongoing project works of Wikimedia and carry on
with the project through Gsoc 2014 and afterwards, become a regular
contributor to Wikimedia.
One can see my username as Wikimedia over here :
https://www.mediawiki.org/wiki/User:Nitinagarwal3006
Github : *https://github.com/NitinAgarwal <https://github.com/NitinAgarwal>*
IRC : nitinagarwal3006
--
*Nitin Agarwal*
Website : www.nitinagarwal.in
.Hi,
There are many articles on wikipedia that contain different units.
Some use cm, that are common in europe, other use inches that are more
widely used in US, same with other unit types.
I think it would be cool if an extension was created which would allow
everyone to specify what units they prefer, and the values in articles
would be converted automatically based on preference.
For example you would say the object has width of {{unit|cm=20}} and
people who prefer cm would see 20 cm in article text, but people who
prefer inches would see 7.87 inch. This could be even based on
geolocation for IP users
What do you think?
Hi all,
We had a fibre cut of our connection to our Tampa DC this morning. ETA
of a fix is still pending, but the cuts have been located and crews
are being dispatched. Meanwhile public traffic is being rerouted via
the public Internet, so most services should be reachable. Tampa is
our secondary DC which we're decommissioning, so there was no impact
on our main sites. Impacted temporarily were: inbound Wikimedia.org
email, Bugzilla, Labs. Fundraising is still impacted, but shouldn't be
(we're debugging).
Thanks to the ops team for their quick response.
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Hello and welcome to the latest edition of the deployment and roadmap
highlights.
Full up-to-date schedule, as always, can be found online at:
<https://wikitech.wikimedia.org/wiki/Deployments>
== Throughout the week ==
* The Technical Operations team will be bringing the west coast caching
center ("ULSFO") online (again, after a failed first attempt due to
connectivity limitations). This work will happen throughout the week.
* On Thursday and Friday there is the MediaWiki Architecture Summit in
San Francisco. See:
https://www.mediawiki.org/wiki/Architecture_Summit_2014
* Due to the US public holiday on Monday (Martin Luther King Jr Day) and
the Architecture Summit, the week of the 20th will be a low/no deploy
week. As such, the only things on the calendar are placeholders for
"Lightning Deploys" on Tues, Wed, and Thurs (Pacific time).
Let me know if you have any questions,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Long message coming up... please be brave and take a look :)
This is a proposal to try and bring order to the messy area of interwiki
linking
and interwiki prefixes, particularly for non-WMF users of MediaWiki.
At the moment, anyone who installs MediaWiki gets a default interwiki table
that
is hopelessly out of date. Some of the URLs listed there have seemingly
been
broken for 7 years [1]. Meanwhile, WMF wikis have access to a nice, updated
interwiki map, stored on Meta, that is difficult for anyone else to use.
Clearly something needs to be done to sort this out.
What I propose we do to improve the situation is along the lines of bug
58369:
1. Split the existing interwiki map on Meta [2] into a "global interwiki
map",
located on MediaWiki.org (draft at [3]), and a "WMF-specific interwiki
map"
on Meta (draft at [4]). Wikimedia-specific interwiki prefixes, like
bugzilla:, gerrit:, and irc: would be located in the map on Meta,
whereas
general-purpose interwikis, like orthodoxwiki: and wikisource: would go
to
the "global map" at MediaWiki.org.
2. Create a bot, similar to l10n-bot, that periodically updates the default
interwiki data in mediawiki/core based on the contents of the global
map.
(Right now, the default map is duplicated in two different formats [5]
[6]
which is quite messy.)
3. Write a version of the rebuildInterwiki.php maintenance script [7] that
can
be bundled with MediaWiki, and which can be run by server admins to pull
in
new entries to their interwiki table from the global map.
This way, fresh installations of MediaWiki get a set of current, useful
interwiki prefixes, and they have the ability to pull in updates as
required.
It also has the benefit of separating out the WMF-specific stuff from the
global
MediaWiki logic, which is a win for external users of MW.
Two other things it would be nice to do:
* Define a proper scope for the interwiki map. At the moment it is a bit
unclear what should and shouldn't be there. The fact that we currently
have
a Linux users' group from New Zealand and someone's personal blog on the
map
suggests the scope of the map have not been well thought out over the
years.
My suggested criterion at [3] is:
"Most well-established and active wikis should have interwiki
prefixes, regardless of whether or not they are using MediaWiki
software.
Sites that are not wikis may be acceptable in some cases,
particularly if they are very commonly linked to (e.g. Google,
OEIS)."
* Take this opportunity to CLEAN UP the global interwiki map!
** Many of the links are long dead.
** Many new wikis have sprung up in the last few years that deserve to be
added.
** Broken prefixes can be moved to the WMF-specific map so existing links on
WMF sites can be cleaned up and dealt with appropriately.
** We could add API URLs to fill the iw_api column in the database
(currently
empty by default).
I'm interested to hear your thoughts on these ideas.
Sorry for the long message, but I really think this topic has been neglected
for such a long time.
TTO
----
PS. I am aware of an RFC on MediaWiki.org relating to this, but I can't see
that
gaining traction any time soon. This proposal would be a more light-weight
way
of dealing with the problem at hand.
[1] https://gerrit.wikimedia.org/r/#/c/84303/
[2] https://meta.wikimedia.org/wiki/Interwiki_map
[3]
https://www.mediawiki.org/wiki/User:This,_that_and_the_other/Interwiki_map
[4]
https://meta.wikimedia.org/wiki/User:This,_that_and_the_other/Local_interwi…
[5]
http://git.wikimedia.org/blob/mediawiki%2Fcore.git/master/maintenance%2Fint…
[6]
http://git.wikimedia.org/blob/mediawiki%2Fcore.git/master/maintenance%2Fint…
[7]
https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FWikimediaMaintenanc…
Heya,
The Program Committee for the Architecture Summit has published a proposed
program: https://www.mediawiki.org/wiki/Architecture_Summit_2014
Highlights of the Program:
1) We have tried to incorporate flexibility into the program by allowing 4
unconference break-out slots, 1 open plenary session and a daily ‘agenda
bashing’ session to make adjustments to the program if the need arises.
2) There are 3 plenary sessions: HTML Templating (
https://www.mediawiki.org/wiki/Architecture_Summit_2014/HTML_templating),
Service Oriented Architecture (
https://www.mediawiki.org/wiki/Architecture_Summit_2014/Service-oriented_ar…)
and one open slot. Possible candidates for the open session include
Performance and UI styling but this will be decided during the Summit. The
short list will include the higher vote-getters in the straw poll, so if
there’s one of the clusters you strongly feel should be part of the
program, now is your time to make that case.
3) There are 6 breakout sessions:
* 2 planned: UI styling (
https://www.mediawiki.org/wiki/Architecture_Summit_2014/UI_styling) and
Storage Services (
https://www.mediawiki.org/wiki/Architecture_Summit_2014/Storage_services)
* 4 unconference slots
There will be a round of Lightning Talks at the beginning of the plenary
session after the breakout session to summarize what happened by answering
the following questions:
a) What did you try to achieve?
b) What did you decide?
c) What are the next steps?
4) Architecture Panel and Value discussion. This is a plenary session for
the architects to share what they value in good architecture, as well as
talk about how they see the architecture of MediaWiki evolving, and what
role people other than our historical core group of three have to play in
the process. During this session, we hope to at least answer some of the
questions outlined in the recent discussion of the RFC process[1]
5) RFC roulette: a one hour closing session for RFC’s that have not been in
the spotlight during the Summit and where the next step can be decided.
This is intended to be fast paced and slightly chaotic. If you would like
to hear what’s next for your RFC please participate with the roulette by
adding your name to
https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_roulette
What does the Program Committee expect from summit participants?
a) If you are a participant, please familiarize yourself with the latest
version of the RFC’s that you care about.
b) If you are an author of an RFC that is scheduled in a plenary session,
please start preparing in collaboration with the other authors from the
same session on a short slidedeck that summarizes all the different RFC’s.
One slide that could be really useful is to have a matrix that highlights
key differences between alternative / competing proposals. Diederik will
contact the folks who are invited for the plenary session to help
coordinate and organize.
c) If you are an author of an RFC that is scheduled in a breakout session,
please create maximum 3 slides that summarize your RFC and think about what
you want to get out of your session. The slides are optional, but the
requisite level of preparation is not.
d) If you want to run an unconference slot then start thinking about a
theme and possible co-organizers. It’s okay to use an existing RFC cluster.
Two quick final notes:
The Program has been created using the input from the straw poll (
https://www.mediawiki.org/wiki/Architecture_Summit_2014/Straw_poll), input
from the Program Committee and input from the Engineering Community Team.
To see which RFC’s compose a cluster please have a look at
https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters
Looking forward to your feedback!
Best regards,
The Program Committee
[1] Discussion of the RFC process:
https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Process#
That's where we are, right?
Some people on outages are reporting no-light on on-campus fibers*; if we
see an uptick in problem reports this morning, that might be why.
Cheers,
-- jra
* specifically DC2 to DC5
--
Jay R. Ashworth Baylink jra(a)baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA #natog +1 727 647 1274
The Paley Center for Media notes on Twitter that Wikipedia is 13 years old
today.
Thanks to Jimmy and He Who Shall Not Be Named, and to Brion, Tim, Mark and
all the hundreds of other dev, ops, admin and outreach people who brought us
to this point; each of you has made it possible for the tens of thousands of
editors of Wikipedia to change the world, one edit at a time.
Nowhere special. I've always wanted to go there.
Cheers,
-- jra
--
Jay R. Ashworth Baylink jra(a)baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA #natog +1 727 647 1274