Here's video from the Discovery/Editing/Reading Showcase on
14-December-2015. Enjoy!
Commons
https://commons.wikimedia.org/wiki/File%3ADiscoverbb_edit.webm
YouTube
https://www.youtube.com/watch?v=U48o_TZLmbY&t=162
In this edition:
* Interactive charts & graphs
* Guided formula (Extension:Math) dialog
* Cross-wiki notifications
* Showing user's preferred languages in Portal top10 wikis.
* A better type-ahead on portals
* Geo search over a bounding box
* Single edit tab
* Wiktionary popup in Android app
* Fuzzy autocomplete on wiki
-Adam
Hi folks,
One thing we're trying to do as we schedule WikiDev '16 is make sure
that sessions are solving for one of five problems. One of the
problems I've been trying to figure out how to articulate I think I've
finally got some wording around, and I'd like your thoughts.
The question: "how do we simultaneously optimize the following
conditions? 1) make software development more logical and obvious for
all Wikimedia contributors, 2) make Wikimedia software more useful and
reliable for the Wikimedia sites"
This is an expression of a balancing tradeoff that I think we've
implicitly made over the years, but I think it's time to make
explicit. Ideally, new ideas should make both better, but sometimes
we need to sacrifice one to make big gains in the other. Does that
question capture an important idea?
A lot more detail in Phab here:
<https://phabricator.wikimedia.org/T119032>
Rob
Yes, if there are wishes that we can't work on -- or we can only do one
part of a larger wish -- then it's our team's responsibility to really
think it through, and report back to the community about it.
We're planning to have some checkpoints through the year, where we'll give
a report on how things are going. The first one is going to be at the
Wikimedia Developers Summit in the first week of January, and after the
Summit we'll publish the information, including notes from the
conversations that we have at the event.
Then there are other Wikimedia events that we can use as checkpoints -- the
Hackathon in April, Wikimania in June -- so that we can keep people updated
about how things are going.
We're also keeping our notes on a Meta page, so interested people can
follow along if they like --
https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Top_10
Right now, that's just notes from some preliminary assessment meetings, so
it's not particularly thrilling, but ideas will get more concrete as we go.
I'm glad people are excited about this year; we are too.
On Wed, Dec 16, 2015 at 7:01 PM, Lane Rasberry <lane(a)bluerasberry.com>
wrote:
> Wow!
>
> I have strong opinions about everything on this list and apparently so do
> many other people.
>
> It was fun to participate in the proposal process.
>
> If any of these proposals are not feasible to develop then I would enjoy
> reading a short explanation explaining why from the perspective of a
> developer to a layman audience.
>
> The entire list seems like magic to me - it is so many things that I want.
>
> yours,
>
>
> On Wed, Dec 16, 2015 at 8:24 PM, Sam Klein <sjklein(a)hcs.harvard.edu>
> wrote:
>
> > Thanks to all for organizing the survey and for sharing!
> >
> > A lot of these should help people stay in touch on smaller wikis and
> > sibling projects where they are less active (and currently less likely to
> > see pings and messages), so while I also want to see wikisource take over
> > the world, these seem like great choices.
> >
> > It's wonderful to see a cross-organization collaboration topping the
> list.
> >
> > Slow migration back to a single unified namespace:
> > #3. Central global repository for templates, gadgets and Lua
> > #4. Cross-wiki watchlist
> > #8. Cross-wiki user talkpage
> >
> > And a mentor-friendly feature I've wanted for a long time:
> > #10. Add a user watchlist
> >
> > SJ
> >
> >
> > On Wed, Dec 16, 2015 at 3:12 PM, Danny Horn <dhorn(a)wikimedia.org> wrote:
> >
> > > Hi everyone,
> > >
> > > I'm happy to announce that the Community Tech team's Community Wishlist
> > > Survey has concluded, and we're able to announce the top 10 wishes!
> > >
> > > 634 people participated in the survey, where they proposed, discussed
> and
> > > voted on 107 ideas. There was a two-week period in November to submit
> and
> > > endorse proposals, followed by two weeks of voting. The top 10
> proposals
> > > with the most support votes now become the Community Tech team's
> backlog
> > of
> > > projects to evaluate and address.
> > >
> > > And here's the top 10:
> > >
> > > #1. Migrate dead links to the Wayback Machine (111 support votes)
> > > #2. Improved diff compare screen (104)
> > > #3. Central global repository for templates, gadgets and Lua modules
> > (87)
> > > #4. Cross-wiki watchlist (84)
> > > #4. Numerical sorting in categories (84)
> > > #6. Allow categories in Commons in all languages (78)
> > > #7. Pageview Stats tool (70)
> > > #8. Global cross-wiki user talk page (66)
> > > #9. Improve the "copy and paste detection" bot (63)
> > > #10. Add a user watchlist (62)
> > >
> > > You can see the whole list here, with links to all the proposals and
> > > Phabricator tickets:
> > > https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
> > >
> > > So what happens now?
> > >
> > > Over the next couple weeks, Community Tech will do a preliminary
> > assessment
> > > on the top 10, and start figuring out what's involved. We need to have
> a
> > > clear definition of the problem and proposed solution, and begin to
> > > understand the technical, design and community challenges for each one.
> > >
> > > Some wishes in the top 10 seem relatively straightforward, and we'll be
> > > able to dig in and start working on them in the new year. Some wishes
> are
> > > going to need a lot of investigation and discussion with other
> > developers,
> > > product teams, designers and community members. There may be some that
> > are
> > > just too big or too hard to do at all.
> > >
> > > Our analysis will look at the following factors:
> > >
> > > * SUPPORT: Overall support for the proposal, including the discussions
> on
> > > the survey page. This will take the neutral and oppose votes into
> > account.
> > > Some of these ideas also have a rich history of discussions on-wiki and
> > in
> > > bug tickets. For some wishes, we'll need more community discussion to
> > help
> > > define the problem and agree on proposed solutions.
> > >
> > > * FEASIBILITY: How much work is involved, including existing blockers
> and
> > > dependencies.
> > >
> > > * IMPACT: Evaluating how many projects and contributors will benefit,
> > > whether it's a long-lasting solution or a temporary fix, and the
> > > improvement in contributors' overall productivity and happiness.
> > >
> > > * RISK: Potential drawbacks, conflicts with other developers' work, and
> > > negative effects on any group of contributors.
> > >
> > > Our plan for 2016 is to complete as many of the top 10 wishes as we
> can.
> > > For the wishes in the top 10 that we can't complete, we're responsible
> > for
> > > investigating them fully and reporting back on the analysis.
> > >
> > > So there's going to be a series of checkpoints through the year, where
> > > we'll present the current status of the top 10 wishes. The first will
> be
> > at
> > > the Wikimedia Developer Summit in the first week of January. We're
> > planning
> > > to talk about the preliminary assessment there, and then share it more
> > > widely.
> > >
> > > If you're eager to follow the whole process as we go along, we'll be
> > > documenting and keeping notes in two places:
> > >
> > > On Meta: 2015 Community Wishlist Survey/Top 10:
> > > https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Top_10
> > >
> > > On Phabricator: Community Wishlist Survey board:
> > > https://phabricator.wikimedia.org/tag/community-wishlist-survey/
> > >
> > > Finally: What about the other 97 proposals?
> > >
> > > There were a lot of good and important proposals that didn't happen to
> > get
> > > quite as many support votes, and I'm sure everybody has at least one
> that
> > > they were rooting for. Again, the whole list is here:
> > >
> > > https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results
> > >
> > > We're going to talk with the other Wikimedia product teams, to see if
> > they
> > > can take on some of the ideas the the community has expressed interest
> > in.
> > > We're also going to work with the Developer Relations team to see if
> some
> > > of these could be taken on by volunteer developers.
> > >
> > > It's also possible that Community Tech could take on a small-scale,
> > > well-defined proposal below the top 10, if it doesn't interfere with
> our
> > > commitments to the top 10 wishes.
> > >
> > > So there's lots of work to be done, and hooray, we have a whole year to
> > do
> > > it. If this process turns out to be a success, then we plan to do
> another
> > > survey at the end of 2016, to give more people a chance to participate,
> > and
> > > bring more great ideas.
> > >
> > > For everybody who proposed, endorsed, discussed, debated and voted in
> the
> > > survey, as well as everyone who said nice things to us recently: thank
> > you
> > > very much for coming out and supporting live feature development. We're
> > > excited about the work ahead of us.
> > >
> > > We'd also like to thank Wikimedia Deutschland's Technischer
> > Communitybedarf
> > > team -- they came up with this whole survey process, and they've been
> > > working successfully on lots of community wishes since their first
> survey
> > > in 2013.
> > >
> > > You can watch this page for further Community Tech announcements:
> > > https://meta.wikimedia.org/wiki/Community_Tech/News
> > >
> > > Thanks!
> > >
> > > Danny Horn
> > > Product Manager, WMF Community Tech
> > > _______________________________________________
> > > Wikimedia-l mailing list, guidelines at:
> > > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > > Wikimedia-l(a)lists.wikimedia.org
> > > <
> >
> https://meta.wikimedia.org/wiki/Mailing_lists/GuidelinesWikimedia-l@lists.w…
> > >
> > > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> >
> >
> >
> >
> > --
> > Samuel Klein @metasj w:user:sj +1 617 529
> 4266
> > _______________________________________________
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > Wikimedia-l(a)lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
> >
>
>
>
> --
> Lane Rasberry
> user:bluerasberry on Wikipedia
> 206.801.0814
> lane(a)bluerasberry.com
> _______________________________________________
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l(a)lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>
>
On Thu, Dec 17, 2015 at 4:01 AM, Lane Rasberry <lane(a)bluerasberry.com>
wrote:
> It was fun to participate in the proposal process.
I want to stress this sentence! I believe many participants will agree.
There are many ways to create a community backlog, and none of them will be
perfect. The Community Tech team chose to have a process relatively simple
to organize and to participate in, doing some sacrifices along the way to
keep that simplicity (I know well, they knocked off several ideas I
suggested). :D
The resulting backlog is just the beginning of a new phase that could be
just as fun. 10 tasks have been selected by CT, and we need everybody's
imagination to find the best ways to solve the rest.
For instance, I'm proposing to select project candidates for hackathons
from this Wishlist (https://phabricator.wikimedia.org/T119703) not only
because it seems a good thing to do, but also because I believe that the
people who voted for these proposals and the developers looking for
interesting hackathon projects can continue having fun together. Achieving
goals is important, but enjoying the ride together is just as important.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Please join for the following tech talk:
*Tech Talk**:* The creation of Histography, from concept to design
*Presenter:* Matan Stauber
*Date:* December 15, 2015
*Time: *20:00 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Tech+Talk%3A+The+c…>
Link to live YouTube stream <http://www.youtube.com/watch?v=PPLA3ktaSbo>
*IRC channel for questions/discussion:* #wikimedia-office
*Summary: *“Histography" is interactive timeline that spans across 14
billion years of history, from the Big Bang to 2015.
The site draws historical events from Wikipedia, self-updates daily and allows
for users to view between decades to millions of years of history.
My name is Matan Stauber, I'm a Graphic Designer and Developer from Tel
Aviv. Graduate of Bezalel Academy of Arts and Design.
UI/UX and Information Desgin are a large part of my work
This Tuesday at 17:00 UTC we'll be switching over from our old
opendj-based ldap servers to new openldap-based ldap servers.
If all goes well, this should be largely unnoticeable to end-users.
Lots of things depend on ldap, though, so we may see some weird,
unpredictable behaviors during the switchover.
During the transition, the old servers will be marked as read-only. For
this reason I advise against doing any stateful work during the
maintenance window. Specifically: account, project and instance
creation on wikitech are likely to misfire in complicated and unpleasant
ways.
Here are some other things which should not break, but require ldap and
are therefore subject to the whims of fate:
- shell auth on all labs instances
- sudo policies on all labs instances
- public dns for the wmflabs.org domain
- all cron jobs on tools
- most of wikitech
- user login to monitoring tools
Moritz, Coren and I will be available on IRC during the scheduled window
to troubleshoot issues if and when they arise.
-Andrew
As part of T113210 [1], which is a broader discussion on track for the
developer summit, I am hosting two IRC office hours back to back [2] on
December 21st from 20:00 UTC to 22:00 UTC.
The previous office hour [3] focused on ways to reconnect to the shared
hosting community. This time two very different topics will be discussed.
*The open questions in the descriptions below are by no means meant to be
exhaustive, nor are they expected to be fully answered by the end of those
office hours. They are just examples to clarify the context of the titles.*
*Shared hosting technical alternatives*
During the last office hour on the topic of non-technical mediawiki
installs, people seemed very eager to discuss new technical solutions that
could offer a viable alternative to shared hosting.
Could new technologies like containers allow for performance/cost ratios
comparable to shared hosting? If not, how big would the penalty be? How
much maintenance would we have to do to keep deployment on such platforms
up to date?
Shared hosting has always suffered from the fact that it's not used at the
WMF and therefore only maintained on a volunteer basis. How would things be
different with new tech?
*Shared hosting support definition*
Shared hosting usage is already a reality and we should do a better job
accounting for it. Currently mediawiki contributors have no visibility in
what should be supported and to what degree. Our browser support is graded
and very clear, meanwhile our server-side support is not:
https://www.mediawiki.org/wiki/Compatibility
Should we model our server-side compatibility guidelines on the graded
system we have for browsers? If so, what would that look like? How could we
break down "shared hosting support" into more discreet server-side
capabilities?
[1] https://phabricator.wikimedia.org/T113210
[2] https://meta.wikimedia.org/wiki/IRC_office_hours#Upcoming_office_hours
[3]
https://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.20…
I see that there's an active workboard in Phabricator at
https://phabricator.wikimedia.org/project/board/225/ for CAPTCHA issues.
Returning to a subject that has been discussed several times before: the
last I heard is that our current CAPTCHAs do block some spambots, but they
also present problems for humans and aren't especially difficult for more
sophisticated spambots to solve. Can someone share a general update on
what's happening with regard to improving usability for humans and
increasing the difficulty for bots? I'm particularly concerned about the
former issue, since CAPTCHAs might be filtering out some good-faith human
editors.
Thanks,
Pine