Hi all!
Today at the ArchoCom-RFC meeting [E355], we will talk about defining an
official thumbnail API [T66214]. At last week's ArchCom meeting, Gabriel said
that at least the first part of this RFC (without the hashing bit) is good for
an IRC meeting. So let's see how for we can get today.
Gabriel, can you say something regarding the status of the RFC, and the desired
outcome of today's meeting? Thanks!
The meeting will be at the usual time (Wednesday 21 UTC, 14 PDT, 23 CET)
and place (#wikimedia-office). For an overview of ArchCOm activity, see
[ArchComStatus].
-- Daniel
PS: my appologies for initially linking to the wrong RFC in [E355].
[E355]: <https://phabricator.wikimedia.org/E355>
[T66214]: <https://phabricator.wikimedia.org/T66214>
[ArchComStatus]: <https://www.mediawiki.org/wiki/ArchComStatus>
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.
Phabricator still has my wikimedia.de Email-Address and tries to confirm
it's me by sending an Email to that address.
Is there a way to reset the email?
(The weird thing is that I seem to receive those Emails on my regular gmail
account, but for logging in it still requires that I verify the wikimedia.de
address? I am a bit confused)
Looping in wikitech-l as well.
<quote name="Huji Lee" date="2016-11-07" time="12:28:09 -0500">
> Dear all,
>
> SecurePoll is an important extension for the WMF community, yet not a whole
> lot of attention has been given to it over the years. I recently became the
> owner of the project, and would like to remind you that with the EN WP
> ARBCOM elections coming up, it would be great if you could help the
> SecurePoll project in the following ways:
>
> 1) Review patches: we have a few outstanding patches that address key
> issues with SecurPoll. They await reviews, especially by those holding +2
> rights. Please spare a moment and review them.
>
> 2) Submit patches: we have quiet a few open tasks for which no patch has
> been submitted. Please spare a moment on this as well.
>
> For your convenience, here are patches awaiting review [1] and here are
> open tasks awaiting a patch. [2]
>
> Sincerely,
>
> Huji
>
> [1]
> https://gerrit.wikimedia.org/r/#/q/project:mediawiki/extensions/SecurePoll+…
> [2] https://phabricator.wikimedia.org/search/query/xlYokZ6kvoMd/
> _______________________________________________
> MediaWiki-l mailing list
> To unsubscribe, go to:
> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team Manager A18D 1138 8E47 FAC8 1C7D |
Hi,
I hit across this idea in the recent GSoC Mentors summit, and in the
> discussion with Srishti and Sumit on the reducing usability and scope of
> GSoC/Outreachy projects[1] among the years.
> *The problem*
> Students show up one or two weeks before GSoC or Outreachy, and propose a
> solution to existing ideas, and often end up completing it and leaving the
> project. Due to this, there is a decline in student-proposed ideas as well,
> given 1-2 weeks is not enough to understand Wikimedia from any direction.
I didn't really understand this. You seem to be talking about some or all
of the following issues:
1) Fewer students doing projects for the Wikimedia Foundation as part of
the Google Summer of Code and, I guess, Outreachy, than in previous
years - 2013
being the high point.
2) Students doing projects that are less useful than in previous years.
3) Students not staying with the Wikimedia/MediaWiki after the conclusion
of their project.
4) Students doing projects proposed by existing MediaWiki developers,
rather than projects they proposed themselves.
I see these as four unrelated issues, and actually I see only two of them
as real issues: #2 I don't think is true (though I'm not sure if that's
what you meant by "usability"), while #4 I don't see as an issue at all.
Personally, I think only projects proposed by potential mentors should be
considered at all, and that the documentation should state that clearly.
I'm not aware of any GSoC projects where the student came up with the idea
on their own and then executed on it successfully - with the exception of
projects where the student is an established MediaWiki developer who
happens to currently be in college, but that's obviously a special case.
It's just not reasonable to expect that someone from outside the
WMF/MediaWiki community would be able to come up with a project that (a)
makes sense, (b) fits within the current development roadmap, and (c) is of
the right scope for a GSoC/Outreachy project.
More generally, I don't think there's anything less rewarding about doing a
project that someone else came up with. In software development, as in most
things, the difficult part - and the most rewarding part - is the
execution, not the original idea. (There are various inspirational quotes
to this effect.)
That leaves #1 and #3 - fewer students participating, fewer students
staying on afterwards. I think #1 is just a function of fewer potential
mentors getting involved. Retaining students, on the other hand, is a real
problem. I can think of various ways to try to improve this, though
creating a new outreach/funding program seems extreme - it would take a lot
of work, and you would presumably run into the same problem of a limited
number of mentors. If there's money to pay for these kinds of things, why
not just put more money into, say, hiring more developers from out of the
GSoC pool? It's one idea.
-Yaron
--
WikiWorks · MediaWiki Consulting · http://wikiworks.com
Hi everyone,
The second annual Community Wishlist Survey starts today, and you're
invited to post proposals for projects that you'd like WMF's Community Tech
team to work on:
https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey
The Community Tech team builds features and makes changes that active
Wikimedia contributors want, and the Wishlist Survey sets the team's agenda
for the year.
The Wishlist Survey starts with a two-week proposal period, when
contributors from all Wikimedia projects are invited to post, discuss and
improve propsals. After that, there's a two-week voting period, when
everyone can post support-votes on the proposals that they think are
worthwhile. We end up with a ranked list of wishes, measured by the
participants' enthusiasm for each idea.
Community Tech is responsible for addressing the top 10 wishes on the list,
as well as some top wishes from smaller groups and projects that are doing
important work, but don't have the numbers to get their proposal into the
top 10. The Wishlist is also used by volunteer developers and other teams,
who want to find projects to work on that the community really wants.
So I hope that everybody comes and participates; it's an opportunity to set
the agenda for a Wikimedia Foundation product team.
We would also ask that you help us spread the word. Please do post on your
wikis and tell others this is happening, and that if they don't feel
comfortable writing in English, proposals are welcome in any language.
Danny Horn
Wikimedia Foundation
Senior Product Manager, Community Tech
Wikimedia is among the 17 organizations in Google Code-in (GCI) 2016!
GCI starts on November 28th. It's a contest for 13-17 year old students
working on small tasks and a great opportunity to let new contributors
make progress and help with smaller tasks on your To-Do list!
What we want you to do:
BECOME A MENTOR:
1. Go to https://www.mediawiki.org/wiki/Google_Code-in_2016 and add
yourself to the mentor's table.
2. Get an invitation email to register on the contest site.
PROVIDE SMALL TASKS:
* Do your docs on your wiki need some improvements?
* Does your template or gadget code needs some updates?
* Do you have small and self-contained bugs you'd love to get fixed?
* Does your UI have small design issues?
* Do your old bugs welcome some testing?
We want your tasks in the following areas: code, outreach/research,
documentation/training, quality assurance, user interface/design.
1. Create a Phabricator task (which would take you 2-3h to complete) or
pick an existing Phabricator task you'd mentor.
2. Add the "Google-Code-In-2016" project tag.
3. Add a comment "I will mentor this in #GCI2016".
Looking for task ideas? Check the "easy" tasks in Phabricator:
https://www.mediawiki.org/wiki/Annoying_little_bugs offers links.
Make sure to cover expectations and deliverables in your task.
And once the contest starts on Nov 28, be ready to answer and review
contributions quickly.
Any questions? Just ask, we're happy to help.
Thank you for your help broadening our contributor base!
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
As of last night the US is no longer on Daylight Savings Time.
This means that for those who are not lined up with United States DST
timings your perception of when deployments happen will change.
As always, the canonical location of when deployments are lives at:
https://wikitech.wikimedia.org/wiki/Deployments
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team Manager A18D 1138 8E47 FAC8 1C7D |