Hi Daniel,
Thanks for the background about wikidata's caching
requirements. A few questions:
1. Will wikidata have any transcludable
pages that contain just infoboxes?
Seems to me that
{{wikidata:en:infobox:Thomas Jefferson}}
could be transformed quite
readily into
[http://www.wikidata.org/wiki/infobox:Thomas_Jefferson/en]
2. Will
wikidata have a page such as [[wikidata:en:Thomas Jefferson]]
(that is
a redirect to [[wikidata:en:WD12345]] as the case may/will be)
showing
all English (& possibly all non-language-specific) subject triples?
3.
Will wikidata have a page such as [[wikidata:Thomas Jefferson]]
that is
a directory of all language-specific (sub-)pages that exist on
wikidata?
Thanks in advance,
John
Hi all,
WMUK is currently advertising for a full-time Developer position. The job description, and info on how to apply, is at:
http://uk.wikimedia.org/wiki/Developer_job_description
My apologies for this post being slightly off-topic, but I'm hoping that this position might be of interest to some subscribers. If you know of anyone that might be interested in this position that isn't on this list, please pass the link on to them!
Thanks,
Mike Peel
Wikimedia UK
Hi,
[cc:ing wikimedia-l because this message is also for Wikimedia users.]
I've been asked to weigh in on this topic, because this is going to be
an area of focus for me over the coming year. I've been tasked with
improving the 2-way communication between users & developers, possibly
using the wikitech-ambassadors list as a medium.
A few people have already explained the scope of the different lists,
but here's my understanding:
* wikitech-l: A high-traffic, unapologetically technical, discussion
list for developers talking to developers
* wikitech-announce: A low-traffic, plain English, announce-only list
for developers talking to Wikimedia users
* wikitech-ambassadors: A (currently) low-traffic, mostly-announce
list for developers talking to Wikimedia users
* mediawiki-announce: A low-traffic, announce-only list for developers
talking to (mostly 3rd-party) MediaWiki users
* wikimediaannounce: A low-traffic, plain English, announce-only list
for general Wikimedia usues.
And the possible change would be for wikitech-ambassadors to become a
medium-to-high-traffic, plain English, list for discussion between
developers and Wikimedia users, to report issues, share ideas and
provide feedback in unapologetically layman terms. The "Ambassadors"
part also means that users who are on that list will have a role in
disseminating information to their local communities, and reporting
back issues possibly raised on local wikis.
FYI, if you're at Wikimania this week, this 2-way communication
channel between developers and users will be a main focus of the
"Transparency" discussion with Sumana, Rob and myself on Saturday 14
at 10:30 in Room 310:
https://wikimania2012.wikimedia.org/wiki/Submissions/Transparency_and_colla…
I've also just noticed that there are two other talks related to this topic:
* Oliver's "Engaging the Community: What We've Tried and Where We're
Going" (Thursday July 12, 11:40, Room 310)
https://wikimania2012.wikimedia.org/wiki/Submissions/Engaging_the_Community…
* Tilman and Max's "Movement Broadcasting - 'Stop Spamming' vs.
'Nobody Told Me" (Thursday, July 12, 14:00, Room 302)
https://wikimania2012.wikimedia.org/wiki/Submissions/Movement_Broadcasting_…
If you can't attend any of those sessions, but you want to discuss /
rant / share ideas about (mis)communication between MediaWiki
developers and Wikimedia users, please come to me at any time during
the hackathon or the conference (If we don't already know each other,
my photo is on https://wikimediafoundation.org/wiki/Staff_and_contractors
)
And if you're not at Wikimania, feel free to drop me an e-mail with
your thoughts on the subject.
--
Guillaume Paumier
Technical Communications Manager — Wikimedia Foundation
Antoine:
Would it be fairly easy for you to get Jenkins to automatically PHP
lint-check new commits to extensions? Code reviewers would thank you!
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
FYI, the following Open Acces paper describes an implementation of DokuWiki
and ABC to make a collaborative environment for music scores.
May be interesting for those that watches the inactivity on
[[bugzilla:189]] (opened on 2004).
http://www.booksonline.iospress.nl/Content/View.aspx?piid=30623
DOI:10.3233/978-1-61499-065-9-82
Best,
[[:m:User:555]]
Hi everyone,
Aaron has been working on bug 37225 for a while:
https://bugzilla.wikimedia.org/show_bug.cgi?id=37225
...but has hit a bit of a brick wall with the bug. I encouraged him
to send mail to the list about it, but he's skeptical that more than a
very small set of people can be helpful on this, which is part of why
I suspect he hasn't sent mail. Please prove him wrong :)
The bug cropped up a few weeks ago, reported May 30. It's hard to say
if this was a bug that was caused by a core change deployed around
that time, an extension deployed around then, or if it was a latent
bug that people just got fed up enough to finally report around that
time. At any rate, it's been a tough one to diagnose.
I think one area where a broad search could be helpful is narrowing
down when this first started happening, and narrowing down which
deployment must have been the issue. Since we're on a biweekly cycle,
it shouldn't be a huge amount of code that contributes to this bug.
For example, someone with enough git-fu and having read the bug
carefully enough might be able to point to a likely culprit revision.
Thanks
Rob
p.s. actually, knowing Aaron and having read the last comment on the
bug, I suspect the reason he didn't send a mail is that he seems to be
close to figuring this out. Still, if someone narrows this down,
that'd really kick butt.
Hello,
Whenever we submit a change in Gerrit, the patchset parent is most
probably not the latest version of master. Hence Gerrit happily merge
our patchsets and thus generate a merge commit. That sometime confuses
people. Note that one can just 'git log --no-merges'.
Gerrit has an option to enforce "Fast Forward Only", that would require
us to press the [Rebase] button before submitting and will result in a
history which is less confused to those not filtering merges commits.
Drawback is that when someone sends a serie of patches, they will need
to be fast forwarded and thus we will somehow loose the fact that those
commits are closely related.
My opinion is to keep the current setting and manually rebase before
submitting. That let us the opportunity to have Gerrit craft a merge
commit when it is actually needed (aka merging a serie of related patches).
--
Antoine "hashar" Musso
One thing I just noticed when looking at the git history via gitk (on
Ubuntu) is that the history looks totally spaghetti and it is hard to
make sense of the history. This seems to have happened since the switch
to git and post-commit review workflow. It might be worth considering
this as well. git pull --rebase (which I assume is being used) usually
helps eliminate noisy merge commits, but I suspect something else is
going on -- post-review commit might be one reason. Is this something
that is worth fixing and can be fixed? Is there some gerrit config that
lets gerrit rebase before merge to let fast-forwarding and eliminate
noisy merges?
Subbu.
Hey all,
Now that we're on a more regular deployment schedule, staying on top of the
blocking bugs and deviding lists into smaller, more managable chunks, is more
and more important.
For that reason I put together a quick tool:
https://toolserver.org/~krinkle/wmfBugZillaPortal/
It is already becoming clear that there is a lot of stuff left behind from past
versions. We should probably start moving stuff to later verisons and keep an
eye on it more regularly.
-- Krinkle