Hi, I'm renaming this spin-off because it has little to do with our real
and urgent quest to find mentors for Outreachy. :)
> > On 9/28/15, Pine W <wiki.pine(a)gmail.com> wrote:
> > > Hi Quim,
> > >
> > > For projects that don't move forward in Outreachy for any reason, is
> > there
> > > a way of suggesting that the particularly useful open projects get WMF
> > dev
> > > time next quarter? It would be nice if there is a way to incorporate
> > > community priorities into quarterly department goal setting.
>
#Possible-Tech-Projects are in fact bad candidates for WMF goals, almost by
design:
* The WMF's efficiency increases when we focus our resources in
urgent/important tasks that volunteers cannot or prefer not to handle
themselves.
* Interns and mentors participating in outreach programs must be allowed to
learn, have fun, and eventually fail, and for that reason we avoid pushing
urgent/important tasks as #Possible-Tech-Projects for volunteers.
There might be a situation where a #Possible-Tech-Project that didn't get
any intern on Q1 is taken as a last team goal or as an individual goal at
the WMF in a future quarter. But this would be an exception, not the norm.
On Mon, Sep 28, 2015 at 9:09 PM, Pine W <wiki.pine(a)gmail.com> wrote:
> I was told by a WMF non-management employee that they have little
> discretion about which projects they're working on, and that the decisions
> about priorities come top-down.
Sometimes priorities come top-down, where "top" actually means different
teams agreeing on common goals, or guidance coming from the annual plans,
the strategy, the board, some kind of consultation, and whatever other
inputs that make sense. Most of the goals in most of the quarters should be
cooked by the own team members based on the priorities agreed by the team
and with their natural neighbors. If a team feels systematically
disempowered by top-down decisions about their own goals, then that is a
problem that needs solving, but not a situation that should be considered
as the norm.
> Hence my interest in engaging with the
> quarterly planning processes and the people managing those processes to see
> if there's a way to get community input into the teams' quarterly goals.
>
As others have said, a good and direct way to propose tasks as quarterly
goals is to go to those tasks and push for them. Find good arguments, align
with other stakeholders, explain why this proposal fits with other ongoing
plans and work... This is exactly what we do when proposing our own goals.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hi folks,
As you saw, the initial call for participation for WikiDev16[1] calls
for session proposals to be in fairly early (due October 2). Many
people have already submitted proposals.[2] It's encouraging to see
this early activity for this.
Let's make sure we plan to talk about what needs to be discussed,
rather than merely what a presenter is comfortable presenting about.
In fact, the word "present" should be a bit of a red flag (where
"present" means "lecture" rather than "gift" and rather than "opposite
of absent")
I made several edits to the WikiDev16/Scope page today[3], where I
attempted to clarify what I think will be the best use of our
collective time. In short, you'll see five different types of
collaborative engineering meetings: "Problem-solving", "Strawman",
"Field narrowing", "Consensus", and "Education". While all types of
discussions are generally productive, for WikiDev16, we should
strongly bias "Problem-solving", "Field narrowing", and "Consensus"
meetings. "Strawman" and "Education" meetings can happen online
and/or in the hallway track[4].
I think we could learn a lot from how the IETF does things, and I
would like to model the bulk of the first two days of WikiDev16 around
the IETF way of doing things. The IETF sets the standard for basic
Internet infrastructure, meeting three times a year in meetings anyone
can register for and attend. I’ve put in a request (T111306) to
purposefully scout the next IETF meeting to give us more knowledge of
their process.[5]
We should strive to show we can build great software in an inclusive,
consensus-oriented, open manner. Let's use this opportunity to figure
out how to make Wikimedia software work better, and make it more
joyful to work with.
Rob
[1] https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016
[2] https://phabricator.wikimedia.org/tag/wikimedia-developer-summit-2016/
[3] https://www.mediawiki.org/wiki/WikiDev16/Scope
[4] http://sachachua.com/blog/2010/12/making-the-most-of-the-conference-hallway…
[5] https://phabricator.wikimedia.org/T111306
You have probably read the announcement of the Wikimedia Developer Summit
2016 registration and call for participation.
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016
I just want to stress that this year we are putting a special emphasis on
inviting not only the developers of MediaWiki core, extensions, and APIs,
but also the "other" developers using this platform to create gadgets,
bots, templates, tools, apps, and third party products relying on Wikimedia
APIs.
We want to increase their participation bringing their own proposals and
joining others' as stakeholders, and we want to meet with them during the
event in San Francisco. We have a modest sponsorship travel budget for
those registering before OCTOBER 2nd (deadline for presentation of new
proposals).
Reaching out to all these developers is not simple, as they are quite
spread. Your help forwarding our invitation to the appropriate communities,
mailing lists, Talk pages, etc, is very welcome.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hi,
I'm one of the developers of thewalnut.io, a platform for authoring and
sharing algorithm visualizations. While working on a visualization of
Langton's ant, I ran into the WikiWidget at
https://es.wikipedia.org/wiki/Hormiga_de_Langton and started looking at how
you guys are doing these, given that it has some similarities to our work.
My idea is that by creating a wikiwidget that can somehow integrate the
content built in the walnut, assuming it gets incorporated into Wikipedia,
it would allow many people to easily create and add interactive
visualizations for algorithms into wikipedia articles with much less work
than now where each wikiwidget for each algorithm needs to be created from
scratch[1]. Instead of just a few wikiwidgets like now it could be
something commonplace in CS related articles. I also see this as an
opportunity to get people from visualization communities closer to the
wikipedia community. And I also see this as an improved experience for
visitors, given that the walnut gives the flexibility to users of modifying
and creating alternate versions of algorithms and visualizations.
So, in short, I'm sending this here to see if the community shares this
interest on moving forward into this direction; specifically if there's
interest on this (I'm more than happy about doing the development work
myself). I'm new here so I'm not even sure if this is the right mailing
list, feel free to redirect me if I'm at the wrong place :)
As a bit of context, I'd like to clarify a few things that I assume might
be relevant for you... I'm not at all an active member in the
mediawiki/wikipedia development community, and a very minor wikipedia
contributor; I'm mostly just a heavy wikipedia user. But I've been an
active participant in many open source project and free software
communities for more than 15 years, so I am quite aware that my invitation
will raise many concerns about the dangers of integrating an external app
that you don't control. I know because I'd have those concerns if I was in
your place. With that in the open I'd like to hear about what we can do to
ease those concerns; if you like the general idea, we're really open to
explore possibilities like releasing code, data, licensing terms on
content, or whatever you think is needed to make this possible.
Thanks for your time,
D.
[1] Just so you have a reference, having an interactive animation about
the langton's ant example took me a bit about 40 minutes; 50 in total if
you count the second visualization I made for density of visits when a
friend asked "are some locations more important than others?"
--
Daniel F. Moisset - Technical Leader
www.machinalis.com
Skype: @dmoisset
I would like to get a skin added as an option to the tarball releases.
What all do they generally need to have done before that's possible?
For reference, this is the skin:
https://www.mediawiki.org/wiki/Skin:GreyStuff
Any feedback about the skin in general would also be appreciated.
-I
I've created this task on the topic of shared hosting:
https://phabricator.wikimedia.org/T113210 as a proposal for the upcoming
Wikimedia Developer Summit.
If anyone on this list is currently running mediawiki on a shared hosting
platform, I would really like to hear from you on that topic, either on the
list or on that phabricator task. So far all the discussions on that
subject I've seen seemed to be done "on behalf" of people relying on those
platforms, and I have yet to hear direct testimonies and opinions from
people who are running mediawiki that way.
The main questions I have for people in that situation are whether there
are blockers for them to move to more modern vm-based or container-based
hosting platforms, or if they prefer to stay on shared hosting for specific
reasons, etc. Basically, tell us why you're on shared hosting for your
mediawiki install(s).
Hello!
MediaWiki-Codesniffer 0.4.0 is now available for use in your MediaWiki
extensions and other projects. Here are the notable changes since the
last release (0.3.0):
* Use upstream codesniffer 2.3.4 (Kunal Mehta & Paladox)
* Sniff to check for space in single line comments (Smriti.Singh)
* Automatically fix warnings caught by SpaceyParenthesisSniff (Kunal Mehta)
* Automatically fix warnings caught by SpaceAfterControlStructureSniff
(Kunal Mehta)
* Add ignore list to PrefixedGlobalFunctionsSniff (Vivek Ghaisas)
* Add ignore list to ValidGlobalNameSniff (Vivek Ghaisas)
* Update jakub-onderka/php-parallel-lint to 0.9.* (Paladox)
* Automatically fix warnings caught by SpaceBeforeSingleLineCommentSniff
(Kunal Mehta)
In this release we started working on automatically fixing errors using
phpcbf (PHP Code Beautifier and Fixer). Support for that is still
experimental and should be considered alpha quality.
-- Legoktm
Hello, wikitech-l,
tl;dr trying to make mw-core pass mw-codesniffer, expect large patches on
Gerrit, and please help
A lot of work has been done on MediaWiki codesniffer
<https://phabricator.wikimedia.org/tag/mediawiki-codesniffer/> (the
PHP_CodeSniffer standard for MediaWiki) over the last few months and this
might be a good time to get core to pass our coding conventions
<https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP>.
Work on this has already started at T102609
<https://phabricator.wikimedia.org/T102609>. There were two primary reasons
to send this email:
1. This is a pretty big task and any help would be very welcome! If we can
get phpcs to run against core's master, it would make every patch
contributors' work a little easier.
2. Work is being organized as subtasks of T102609, and has been divided on
the basis of sniffs. Because of this, every patch is going to change a lot
of unrelated files and a lot of reviewers are going to get added on Gerrit.
Let's make this happen!
Vivek Ghaisas (polybuildr)
On Fri, Sep 25, 2015 at 11:52 AM, Purodha Blissenbach
<purodha(a)blissenbach.org> wrote:
> There has been a project in the past that converted a MediaWiki code base
> from SQL to use svn or git as message store. I do not remember which. It
> worked afaicr but was discontinued as not being used irl, and pretty slow,
> too.
If you could dig up more details on that project I'd be very
interested! Those who don't learn from history, etc. I'd love to
read through the code and see what was done. It would be relevant to
https://phabricator.wikimedia.org/T113004
--scott
Hello!
The Wikimedia Developer Summit 2016 will be taking place in San Francisco,
CA between January 4th and January 6th, 2016.
Registration is open along with the call for participation.
*Deadline for travel sponsorship requests and the call for participation is
October 2, 2015.*
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016
Hope to see you in San Francisco!