If I want to show anonymous users a message including "You can _login_ or
_create an account_ " with returnto support, what's the best way to do it?
Background:
All over MediaWiki we display messages to anonymous users with "_login_ or
_create an account_" links in them. In most cases we want the user to
easily get back to what they were doing, so Special:UserLogin supports
returnto and returntoquery parameters which after login or signup make it
display a link to go back to the page the user was on, or silently redirect
back to it.
The display of login/signup links seems haphazard:
1) Many messages don't bother with returnto, and just have wiki links to
the special page. E.g. anontalkpagetext has:
please [[Special:UserLogin/signup|create an account]] or
[[Special:UserLogin|log in]] ...
2) Some messages try to handle returnto with complicated magic word
processing, , e.g. https://en.wikipedia.org/wiki/MediaWiki:Anoneditwarning
has:
If you '''[{{fullurl:Special:UserLogin|returnto={{FULLPAGENAMEE}}}} log
in]''' or
'''[{{fullurl:Special:UserLogin/signup|campaign=anoneditwarning&returnto={{FULLPAGENAMEE}}}}
create an account]''' ...
This is fiddly, the magic words don''t work in JavaScript, and the
resulting HTML requires you put class=plainlinks on the enclosing tag to
disable the display of the external link icon. On the plus side it's
generated entirely in the message string, and wiki admins can tweak
parameters, like the signup campaign parameter in this example.
3) Often code builds the login/signup links in PHP and passes them to the
message.
3a) OutputPage-> showPermissionsPage() builds a login URL with
Linker:LinkKnown. It doesn't provide a sign up link, and the code to build
the login link can't be reused. Which may be why
WatchAction->checkCanExecute() and SpecialPage::requireLogin copy and paste
the code.
3b) SkinTemplate.php generates the Login / Create account URLs at the top
right of most skins using Skin::makeSpecialUrl. But you can't pass this to
a message because it may not start with //myserver.com and if it doesn't
then it won't work in a [$1 link text] link.
Thanks for any advice,
--
=S Page Features engineer
On Mon, Jun 16, 2014 at 4:10 PM, Chad <innocentkiller(a)gmail.com> wrote:
>
> > That gerrit.wikimedia.org doesn't seem to have any of the standard
> > footnote
> > links (including the privacy policy, which is perhaps a more significant
> > oversight)...is that because of the interface? One would think a custom
> > skin could be developed that would permit inclusion of such links.
> >
>
> One would think. Too bad it's basically impossible to skin Gerrit
> without hacking its core.
We're aware of this, but have held off handling it until the Phabricator
transition, so that we can handle in one place and also put one, more
appropriate policy in place, rather than different ones for different
projects.
Luis
--
Luis Villa
Deputy General Counsel
Wikimedia Foundation
415.839.6885 ext. 6810
*This message may be confidential or legally privileged. If you have
received it by accident, please delete it and let us know about the
mistake. As an attorney for the Wikimedia Foundation, for legal/ethical
reasons I cannot give legal advice to, or serve as a lawyer for, community
members, volunteers, or staff members in their personal capacity. For more
on what this means, please see our legal disclaimer
<https://meta.wikimedia.org/wiki/Wikimedia_Legal_Disclaimer>.*
(If you are a Google Summer of Code mentor, read till #The_end)
Summer has not even started in the Northern Hemisphere, but GSoC mid-term
evaluations are just around the corner. All GSoC participants will receive
specific instructions and reminders from Google directly. Let me insist in
the most basic points:
* The evaluation period goes from 19:00 UTC on Monday, 23 June to 19:00 UTC
on Friday, 27 June. Submit your report soon. Google makes no exceptions
with participants missing the deadline.
* All students must evaluate their mentors. If a student misses this
evaluation, they will be removed from the program. Game Over.
* Every student must be evaluated by one mentor (and only one, if the
process is like last year). If one mentor misses the deadline, then that
mentor cannot attend the Google Summer of Code Reunion (see below) and will
bring trouble to their project. If two or more mentors miss this deadline
then the whole Wikimedia organization will be banned at the GSoC Reunion,
and everybody will get their dose of shame.
These evaluations are private. Students are not supposed to access the
mentor's evaluation, and vice versa. However, students and mentors of each
project are encouraged to meet and have a good conversation about the
status of the project and the next steps.
FOSS Outreach Program for Women participants, although these mid-term
evaluations are obligatory for GSoC participants only, you are also
encouraged to go through them. We will send you an email with the same
questionnaire. This way we keep both programs in equal terms.
The_end
If you want to be a Wikimedia delegate at the Google Summer of Code
Reunion, apply before the end of June at
https://www.mediawiki.org/wiki/Talk:Mentorship_programs/Possible_mentors
PS: I will be on holidays and travelling between June 25 and July 6. If you
need help from an org admin please send your questions to Andre, Rachel
(both CCed here), and myself.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
The other mail seems to have gone on a huge tangent about the benefits
of Flow / what it can do. This is great but I feel like my original
question has gone unanswered so I am resurrecting it with a new e-mail
subject. I worry lots of good feedback got lost in that big email
chain.
So hypothetically... If we switched over from the unmaintained
LiquidThreads (LQT) to the maintained Flow what would happen? [By this
I mean on every page regardless of namespace that LQT is we enable
Flow instead.]
Some top level questions to get started:
1) Do we need to import all conversations over OR can we just switch
to a blank page to get started from?
2) What can you do in LQT that you cannot do in Flow? (Please do not
include issues with design - this is a new product that can be
redefined as it is developed on)
3) Any other concerns?
Jon
Excerpt from the blog post:
https://blog.wikimedia.org/2014/05/27/request-for-proposals-mediawiki-relea…
--
Last year, the Wikimedia Foundation started to share the
responsibility[0] of the long term management of the MediaWiki software
project with the wider community. We are continuing the process with a
second Request for Proposals[1] to manage the third-party releases of
MediaWiki (PDF[2]).
The process for this RFP is a community-involved one. There is a
three-week period for organizations to prepare and submit their
proposals, after which the community can comment on and ask questions of
the proposers. The Wikimedia Foundation will take all of this feedback
into account when making the final decision for who will lead the
release management of MediaWiki for the next year.
The deadline for proposals is June 13.
Please do get involved if you are interested in the future of MediaWiki!
Greg
[0] https://blog.wikimedia.org/2013/05/21/request-for-proposals-mediawiki-relea…
[1] https://www.mediawiki.org/wiki/Release_Management_RFP
[2] https://commons.wikimedia.org/wiki/File:MediaWiki_Release_Request_For_Propo…
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
> Date: Wed, 04 Jun 2014 02:12:30 -0700
> From: Daniel Friesen<daniel(a)nadir-seen-fire.com>
>
> On 2014-06-04, 1:29 AM, Legoktm wrote:
>> >== Extension locations ==
>> >We agreed that we should require extensions to all be in the same
>> >directory, but that directory should be configurable. By default it
>> >will point to $IP/extensions.
> I still do NOT like this idea.
>
> By all means there should be one directory for extensions that are
> managed by a web/cli installer and the method of loading extensions from
> that one directory should be simple even when we're still using a php
> settings file. But when someone is intentionally not using that and
> doing complex config then we shouldn't stop them from saying to load an
> extension from a specific directory.
+1
Minutes and slides from Wednesday's quarterly review meeting of the
Foundation's Growth (formerly E3) 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
Hello everyone,
It’s with great pleasure that I’m announcing that Elliott Eggleston will be joining the Wikimedia Foundation as a Features Engineer in Fundraising-Tech.
Before joining us, Eliott was a senior software engineer at SAI Global[1], and before that at Integrity Interactive (which was bought by SAI Global), which means he’s been working diligently for seven years in enterprise software development. Surprisingly, we didn’t hold this too much against him.[2] ;-)
His first official day is Monday June 16th where he will be in the office. He is going to work with the Fundraising Tech team under Katie Horn and along with Adam Wight and Sherah Smith on whatever voodoo there manages to pay our salaries (and adds to secret account in the Caymans I had them set up[3]), as Matthew Walker transitions to Services[4] this year.
He received his Bachelor’s in Computer Science from Columbia in 2004 and spends his down time writing an Android application[5], making a website to map his music listening-bike route, playing Scrabble, and taking 3-d pictures. He lives in Somerville, Massachusetts.
Oh yeah, he’s also a childhood friend of Adam Wight. (Ask them to serenade you with the pi song they invented as kids.) I don’t know whether I should be excited to have a person whose disciplined work and even temper can talk Adam back from the ledge, or to be worried that they might tag team another thread on WMF-all demanding the Foundation to be a co-op.
Please join me in a welcoming Elliott to the Wikimedia Foundation. :-)
Take care,
Terry
P.S. In keeping with Jared’s demand of a picture to accompany every new hire announcement, here is one: https://abs.twimg.com/sticky/default_profile_images/default_profile_3_200x2…
[1] http://www.saiglobal.com
[2] We only made him do four coding tests during the hiring process.
[3] As a hedge if all my wikishares don't vest.
[4] https://www.mediawiki.org/wiki/Wikimedia_Engineering/Service_and_REST_API_t…
[5] Erik Möller is of the opinion working a Java Android app for manipulating 3D fractals with a web export that works in latest versions of Firefox on mobile devices with WebGL is not the kind of thing you do for fun if you don’t enjoy complex challenges. I am of the opinion that Java PERIOD itself is not the kind of thing you do for fun PERIOD.
[6] Not sure this is any better: https://github.com/ejegg
terry chay 최태리
Director of Features Engineering
Wikimedia Foundation
“Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment.”
p: +1 (415) 839-6885 x6832
m: +1 (408) 480-8902
e: tchay(a)wikimedia.org
i: http://terrychay.com/
w: http://meta.wikimedia.org/wiki/User:Tychay
aim: terrychay
