Hey,
Regarding
https://github.com/wikimedia/mediawiki-core/blob/793f17481ea937275898c91b9b…
So now all extensions that want to retain compatibility with MediaWiki 1.22
and at the same time not have deprecation notices on 1.23 need to do an
if-else for all calls to this method? That sucks big time. And for what?
The old method is just forwarding to the new one. All this hassle for a
rename? How about removing the wfDeprecated call and not annoying all
extension maintainers?
Cheers
--
Jeroen De Dauw - http://www.bn2vs.com
Software craftsmanship advocate
Evil software architect at Wikimedia Germany
~=[,,_,,]:3
Might be relevant
---------- Forwarded message ----------
From: "Kenan Wang" <kwang(a)wikimedia.org>
Date: Apr 5, 2014 4:37 AM
Subject: [WikimediaMobile] Notes from discussions about reverts on mobile
To: "mobile-l" <mobile-l(a)lists.wikimedia.org>
Cc: "Moiz Syed" <msyed(a)wikimedia.org>, "Kaity Hammerstein" <
khammerstein(a)wikimedia.org>
Editors want to be able to patrol edits on pages that they care about.
> Currently they use:
> 1) Watchlist
> 2) Article History
> 3) Recent Changes
>
> The mechanism for “fixing” a problem with an edit is doing a revert.
> Reverting allows you to go back to a revision of the article that existed
> before the change that you want to “fix”. Specifically it populates an edit
> with the content of that previous revision and then you are actually able
> to make any additional changes on top of that old content and then save.
>
> There are two special cases of reverting that are especially useful to
> users:
> 1) Undo - this is when you want to “fix” an edit but there have been edits
> since the problematic edit that were productive. Undo tries to just undo
> that specific edit in question instead of reverting all the way to the
> revision before the edit. The reason to use undo is that sometimes there
> was a problematic edit but since then there have been productive edits.
> Specifically, what undo does is it tries to revert to the revision before
> the problematic edit and then computationally add back in the edits since
> then. Sometimes this isn’t possible. Sometimes it is. When it is possible
> to undo automatically the user gets the revision plus the “productive
> edits” that occurred since the edit being undone, all of that content is
> populated into an edit interface and the user can make any additional edits
> (sometimes necessary to make the article make sense after the undo) and
> then save.
>
> 2) Rollback - this is when you take all of the edits of the last user and
> revert to the revision before those edits. The purpose of this is when
> there is a user that has been committing vandalism you can quickly rollback
> those edits. This is a one step process because it just does the revert and
> saves automatically.
>
> note 1: generally speaking vandalism gets caught quickly and is often the
> most recent or most recent set of edie by a single user i.e. the situation
> that rollback is designed for
>
> note 2: undo occurs on an edit, revert and rollback operate on revisions.
> on desktop the list of edits and the list of revisions is the same
> interface but it may make sense to divide these on mobile. Thus on mobile
> we may have separately a list of revisions (possibly grouped by user) that
> may allow reverts and rollbacks, and a list of edits that allows for unto.
>
> We will likely prioritize revert/rollbacks because that covers the biggest
> use case (vandalism on articles that are changing at a moderate velocity. Also,
> this may have implications for how we display watchlist items: considering
> grouping edits by user, and only displaying most recent edits (i.e. only
> rollback eligible edits)
>
> There a detailed view of revisions in addition to a list view of
> revisions and. We need to understand what goes into a detailed view of a
> revision. Maybe we show the diff to current version because this is what
> would be affected by a revert, actions, username, time, other details.We
> may want to consider changing the interaction of reverts a bit (maybe
> should be 2 click action instead of putting user into edit).
>
> Let me know if I missed anything.
>
> --
>
> Kenan Wang
> Product Manager, Mobile
> Wikimedia Foundation
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
On Friday, April 4, 2014, Happy Melon <happy.melon.wiki(a)gmail.com> wrote:
> On 4 April 2014 00:38, Brian Wolff <bawolff(a)gmail.com <javascript:;>>
> wrote:
>
> >
> > > what about directing new volunteers there, asking them to submit their
> > code
> > > revisions. For a patch that has been waiting in silence for over a
> year,
> > > any feedback will be better than no feedback.
> >
> > You sure about that? I would imagine that having no one look at your code
> > for months, then having someone who doesn't have the authority to approve
> > it
> > nit pick it a little, followed by another couple months of waiting, to be
> > more frustrating then no feedback at all.
>
No, I'm not sure. Now those changesets are buried somewhere. The hypothesis
is that channeling some attention to them cannot make things worse. Perhaps
the nitpicking helps to bring back the attention of the maintainers?
Maybe we can dig deeper in the metrics, and find changesets with last
versions of patches waiting for a first review, a different case from, say,
open changesets with many versions, many comments and some +1 (a place
where a newcomer would not add much).
> This is also completely the wrong way to go about open-source development.
> The work priorities of volunteers are the thing that you, as manager of
> paid staff, *can't* control, as opposed to the work priorities of paid
> staff, which you very much can.
Agreed, and one of the reasons for producing these metrics is to help paid
developers prioritize their work taking into account the task of reviewing
the contributions they receive. However...
> If reviewing these old patches was in any
> way interesting/exciting/fulfilling, volunteers would probably already have
> *made* some contributions.
This would be true if such potential contributions could be easily found by
new contributors. Currently they are well hidden, you really need to know
where to go in order to find a Gerrit changeset welcoming feedback.
Can we define URLs to Gerrit queries to be advertized at
https://www.mediawiki.org/wiki/Annoying_little_bugs ? For instance, we
offer links to EASY bugs, and looking at the paths chosen by e.g. potential
GSoC candidates I would say that the system kind of works.
> Being occasionally tasked with
> uninteresting/unexciting/unfulfilling tasks that Just Need Doing is one of
> the things that paid developers *get *paid *for*.
Many tasks that are considered uninteresting/unexciting/unfulfilling by
experienced contributors are interesting/exciting/fulfilling for new
contributors. Again, the EASY bugs are a good example. Ideas to define good
tasks for newcomers in our review queues are welcome.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hello,
https://bugzilla.wikimedia.org/show_bug.cgi?id=24620
What is the status on this bug exactly. I ran across it, but don't really know
enough about the i18n system to figure out if the problem was fixed.
Alternatively it could be that I simply don't know what I am doing in Bugzilla
in general (something I hope to fix).
Would anyone be willing to let me know where this bug stands, or close it if it
should be closed?
Thank you,
Derric Atzrott
Computer Specialist
Alizee Pathology
Hello and welcome to the latest edition of the WMF Engineering Roadmap
and Deployment update.
The full log of planned deployments next week can be found at:
https://wikitech.wikimedia.org/wiki/Deployments#Week_of_April_7th
Notable items...
== Tuesday ==
* The backend to the new search system (ElasticSearch) will be upgraded
* to 1.1.0
** This should not affect users in any negative way.
* MediaWiki deploy
** group1 to 1.23wmf21: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.23/wmf21>
* Wikiquote will get language links via Wikidata
** <https://www.wikidata.org/wiki/Wikidata:Wikiquote>
== Thursday ==
* MediaWiki deploy
** group2 to 1.23wmf21 (all Wikipedias)
** group0 to 1.23wmf22 (test/test2/testwikidata/mediawiki)
* Media Viewer - First limited pilot release: Enable by default on
* MediaWiki.org
** <https://www.mediawiki.org/wiki/Multimedia/Media_Viewer>
As always, questions welcome!
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Now that TitleValue has been merged - what's next? I'll admit I'm an odd
choice to be sending out this email [1], but someone's got to do it. So,
I'm thinking, maybe:
1. Start on the TODO in Linker.php [2], turning it into a deprecated
compatibility interface calling HtmlPageLinkRenderer.
2. Start writing code in the same fashion for an upcoming project. I
believe the upcoming revision storage work might lend itself well to this.
Also, I think we should think about how we want interdependent components
to come together. Right now everything must know how to make all of its
dependencies. For example, LinksSearchPage must know how to build
MediaWikiTitleCodec. That isn't a hardship now, but might become one when
we have 30 things like LinksSearchPage and we want to add another
dependency to MediaWikiTitleCodec.
I don't claim to know a whole lot about the state of the art for this
problem in PHP but I'm used to solving it with an inversion of control
container. Each component declares its dependencies in some way and the
container makes sure that each component gets the dependencies it needs.
Do we need something like this now or will we need something like this in
the future?
Nik/manybubbles
[1]: I was the most against TitleValue at the Architecture Summit but have
since softened my opinion. Also, the vast majority of my work is in the
CirrusSearch extension and not core.
[2]: https://gerrit.wikimedia.org/r/#/c/106517/22/includes/Linker.php,cm
Minutes and slides from Monday's quarterly review meeting of the
Foundation's Analytics team are now available at
https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
.
On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote:
> Hi folks,
>
> to increase accountability and create more opportunities for course
> corrections and resourcing adjustments as necessary, Sue's asked me
> and Howie Fung to set up a quarterly project evaluation process,
> starting with our highest priority initiatives. These are, according
> to Sue's narrowing focus recommendations which were approved by the
> Board [1]:
>
> - Visual Editor
> - Mobile (mobile contributions + Wikipedia Zero)
> - Editor Engagement (also known as the E2 and E3 teams)
> - Funds Dissemination Committe and expanded grant-making capacity
>
> I'm proposing the following initial schedule:
>
> January:
> - Editor Engagement Experiments
>
> February:
> - Visual Editor
> - Mobile (Contribs + Zero)
>
> March:
> - Editor Engagement Features (Echo, Flow projects)
> - Funds Dissemination Committee
>
> We'll try doing this on the same day or adjacent to the monthly
> metrics meetings [2], since the team(s) will give a presentation on
> their recent progress, which will help set some context that would
> otherwise need to be covered in the quarterly review itself. This will
> also create open opportunities for feedback and questions.
>
> My goal is to do this in a manner where even though the quarterly
> review meetings themselves are internal, the outcomes are captured as
> meeting minutes and shared publicly, which is why I'm starting this
> discussion on a public list as well. I've created a wiki page here
> which we can use to discuss the concept further:
>
> https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
>
> The internal review will, at minimum, include:
>
> Sue Gardner
> myself
> Howie Fung
> Team members and relevant director(s)
> Designated minute-taker
>
> So for example, for Visual Editor, the review team would be the Visual
> Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker.
>
> I imagine the structure of the review roughly as follows, with a
> duration of about 2 1/2 hours divided into 25-30 minute blocks:
>
> - Brief team intro and recap of team's activities through the quarter,
> compared with goals
> - Drill into goals and targets: Did we achieve what we said we would?
> - Review of challenges, blockers and successes
> - Discussion of proposed changes (e.g. resourcing, targets) and other
> action items
> - Buffer time, debriefing
>
> Once again, the primary purpose of these reviews is to create improved
> structures for internal accountability, escalation points in cases
> where serious changes are necessary, and transparency to the world.
>
> In addition to these priority initiatives, my recommendation would be
> to conduct quarterly reviews for any activity that requires more than
> a set amount of resources (people/dollars). These additional reviews
> may however be conducted in a more lightweight manner and internally
> to the departments. We're slowly getting into that habit in
> engineering.
>
> As we pilot this process, the format of the high priority reviews can
> help inform and support reviews across the organization.
>
> Feedback and questions are appreciated.
>
> All best,
> Erik
>
> [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus
> [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings
> --
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
>
> Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate
>
> _______________________________________________
> Wikimedia-l mailing list
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
--
Tilman Bayer
Senior Operations Analyst (Movement Communications)
Wikimedia Foundation
IRC (Freenode): HaeB
Hi,
we had a short meeting this morning to discuss our Debian packaging and
repository plans for WMF-developed software. The meeting notes are now
posted at
https://www.mediawiki.org/wiki/Talk:Packaging#Meeting_notes_2014-04-04
We agreed to set up a public repository at releases.wikimedia.org fairly
soon. The goal with this public repository is to make it easy for engineers
to release Debian packages to the general public without the thorough code
review and manual upload needed for internal packages on apt.wikimedia.org.
Automatic package builds and uploads will likely be triggered by adding a
release tag in gerrit. The longer-term hope is to provide everything needed
to make 'apt-get install mediawiki-full' install & configure a
fully-featured MediaWiki environment including caching, Parsoid, PDF
renderer and the kitchen sink.
For now the repository will only have a catch-all 'unstable' section that
can be used for tested, but frequently released packages like Parsoid (in
sync with deploys, typically twice per week). We have not made a decision on
how to structure stable releases for unattended upgrades and security yet.
Generally there was a lot of support for keeping our Debian packaging
pragmatic, without enforcing strict Debian guidelines to the letter in the
first iteration of every new package. We'd like to work with Debian and have
most of our packages eventually become official packages, but we also won't
shy away from creating something like a mediawiki-full configuration
meta-package that might not be acceptable in Debian itself.
Gabriel
http://notwaldorf.github.io/posts/code-reviews/
One perspective. (was: Subject: Code review tasks for new contributors)
--
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation