ICANN just delegated the gTLD .WIKI yesterday. It's being managed by Top Level
Design, LLC. I'm not entirely sure what that means for all of us exactly, but I
suspect that the WMF is going to want to at least register Wikipedia.wiki and
Wikimedia.wiki once the gTLD is open for registration.
Some of the new gTLDs are already opening up for registration. .sexy and
.tattoo will be opening for registration on 25 February.
It looks like if we want to get .wiki domains we will be getting them sometime
in May or June during the "sunrise" period.[1]
ICANN also has a full list of new gTLDs that they have approved.[2]
Thank you,
Derric Atzrott
Computer Specialist
Alizee Pathology
[1]: http://www.namejet.com/Pages/newtlds/tld/WIKI
[2]: http://newgtlds.icann.org/en/program-status/delegated-strings
2014-04-02 16:36 GMT+03:00 Max Semenik <maxsem.wiki(a)gmail.com>:
> On 02.04.2014, 17:32 Strainu wrote:
>
>> Yes. And that would be more useful than a map with a single coordinate
>> of whatever happens to be the first mountain in the list.
>
> Nope, lists should have no primary coordinates at all. Still, what's
> the real use case for such lists with unnamed points other than
> "because we can"?:)
Can we please keep the discussion on list?
First of all, I don't think the use-case I presented is equivalent to
"because we can". But here is another usecase: When I parse
coordinates from articles or pictures, I try to get them from the
database because it's faster and more reliable than parsing the
geohack link. If tomorrow 90% of that database dissapears because it
has no "name" (something I couldn't care less about) and some obscure
template does not mark the coordinates as primary, the running time of
my robots will probably increase by 30-50%.
Adding names to coordinates is not something most people do, at least
on small wikis. I admit I have no idea how to do it. If I'll ever feel
the need, I'll read the docs and apply the method, but I can't send
everybody to read technical documentation just because you decided to
remove a feature that works fine just because you think it's
"useless".
>From the moment the feature went live on the Wikimedia sites, it is at
the very least preferable, if not compulsory to think about backwards
compatibility and only remove a feature if we're reasonably sure we're
not going to affect a lot of people.
Strainu
2014-04-02 15:18 GMT+03:00 Max Semenik <maxsem.wiki(a)gmail.com>:
> On 02.04.2014, 15:20 Strainu wrote:
>
>> You don't really need to tell the coordinates apart in order for them
>> to be useful. One of the things that I would like to do / see done at
>> some point in
>> https://toolserver.org/~kolossos/openlayers/kml-on-ol.php
>> is an option to display only the coordinates _in the current page_.
>> This would be useful on pages with large numbers of coordinates
>> (mostly lists) even without a way to nominate them. Granted, having a
>> name would help, but it doesn't seem compulsory to me.
>
> And what will it result in? A map with a thousand "List of mountains
> in Antarctica" points?
Yes. And that would be more useful than a map with a single coordinate
of whatever happens to be the first mountain in the list.
Strainu
Hi, I'd like a sanity check on my plans to reduce the GeoData index. I
plan to:
1) Not store coordinates from pages outside of content namespaces:
main and file.
2) Not store secondary coordinates that don't specify the coordinate
name. There is currently a bunch of secondary coordinates that make no
sense because there's to way to tell them apart or tell what are they
for.
I hope that these measures will make our database of geographical
coordinates more useful on average, but please tell me if there's a
fatal flaw in my plans:)
--
Best regards,
Max Semenik ([[User:MaxSem]])
Minutes and slides from Wednesday's quarterly review of the
Foundation's VisualEditor team are now available at
https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r…
(A separate but related quarterly review meeting of the Parsoid team
took place today, those minutes should be up on Monday.)
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 everyone,
As I'm sure most of you are aware, Hovercards is now live as Beta Feature
[1]. Prateek, the developer for Hovercards, has been a bit stuck recently
trying to find someone to review his patches. We'd appreciate any help that
anyone could offer on this front! Hovercards is mostly written in JS, for
reference.
Watch out for commits from Prtksxna (psaxena(a)wikimedia.org), or let me know
if you're interested in helping more directly.
Thanks,
Dan
[1]:
http://blog.wikimedia.org/2014/03/26/hovercards-now-available-as-a-beta-fea…
--
Dan Garry
Associate Product Manager for Platform
Wikimedia Foundation
On Tue, Apr 1, 2014 at 11:46 AM, Aalekh Nigam <aalekh1993(a)rediffmail.com>wrote:
> Hello,
>
> I am currently working on Multilingual and effective Captcha project for
> GSOC 2014 just to
> encounter the same problem of difficult image I did proposed the solution
> as an indexing System
> for image which will improve overtime by removing non user friendly images
> from those user
> friendly, more detail about this image indexing system is discussed here:
>
>
> https://www.mediawiki.org/wiki/User:AalekhN/GSoC_proposal_2014#Image_Indexi…
>
That sounds awesome. Please let me know if I can help beta test it.
Ryan Kaldari
Has anyone ever collected statistics on which of our captcha images are
most commonly entered incorrectly? I've noticed that some of our images are
quite difficult to read and should probably be removed from rotation. I
could imagine applying a heuristic like:
0-10% wrong: Delete - too easy
10-30% wrong: Keep - just right
30-100% wrong: Delete - too hard
Ryan Kaldari