Re: [Wikitech-l] Help on creating a new extension

[Nischay Nahata]

On Sat, Nov 23, 2019 at 1:06 AM Sohom Datta  wrote:

> Hi,
>
> The first two questions were actually intended to be implementation
> questions, specifically on whether it is possible to implement the two
> features that I thought about ?
>
> However, now that you mentioned it, it certainly would be great if some
> experienced contributors could co-maintain and help me with creating the
> extension.
>
> Also, by official extension I mean like the extensions that have a page on
> the MediaWiki wiki and are hosted on Gerrit. :)
>
>
>
Anyone can create a page for an extension and you can also request for your
extension to be hosted on Gerrit - it helps a lot of if you are looking at
localisation of the extension. Nothing official here here, however if there
is something official it would probably mean the extension is used on one
of the Wikimedia wikis.


> On Sat, Nov 23, 2019, 12:37 AM Andre Klapper 
> wrote:
>
> > Hi and thanks for your email (and code)! :)
> >
> > On Fri, 2019-11-22 at 23:54 +0530, Sohom Datta wrote:
> > > Hi guys, I'm Sohom Datta.
> > >
> > > I recently decided to create a draft for an hypothetical extension
> > > ProtectionIndicator, which will add a protection icon on the top of
> every
> > > protected page. I did this primarily out of my own interest in getting
> > > familiar with the code-base of MediaWiki.
> > >
> > > I've hosted all the code I have written (still unfinished) in this
> github
> > > repository <
> > > http://github.com/sohomdatta1/ProtectionIndicator
> > > >.
> > >
> > > I'd like some guidance on how to implement the unfinished parts of the
> > > extension especially the integration with FlaggedRevs and the addition
> > of a
> > > log entry to a popup ( Details are there in the readme.md of the repo)
> .
> > > Also any feedback on my code would also be very good.
> >
> > Is this a call for potentially interested co-maintainers?
> > Or do you have specific implementation questions to share?
> >
> > > Also, it would be great if somebody could guide me on how to make this
> a
> > > official extension someday.
> >
> > Could you elaborate what "official" means, and what you expect from it?
> >
> > Thanks!
> > andre
> > --
> > Andre Klapper (he/him) | Bugwrangler / Developer Advocate
> > https://blogs.gnome.org/aklapper/
> >
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Add modules=site.styles inline

[Nischay Nahata]

Okay, that's good to know. I am still on 1.26 so it may have changed at a
later stage.

Thank you

On Fri, Jul 20, 2018, 9:20 PM Bartosz Dziewoński 
wrote:

> Also, I should note that I tested with MW 1.32 alpha (Git master).
> I don't know if older versions behave differently.
>
> --
> Bartosz Dziewoński
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Add modules=site.styles inline

[Nischay Nahata]

I tried that, its still showing up.

Regards,
Nischay Nahata


On Fri, Jul 20, 2018 at 4:28 PM Bartosz Dziewoński 
wrote:

> The  will not be generated if the page is actually deleted, rather
> than existing but empty.
>
> --
> Bartosz Dziewoński
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Add modules=site.styles inline

[Nischay Nahata]

It loads the link even though the content is blank :/

Regards,
Nischay Nahata


On Fri, Jul 20, 2018 at 11:25 AM Nischay Nahata 
wrote:

> Thanks for the reply.
>
> I do use the file cache and yes, there could be performance issues with
> purging too many problems at once. But again there's a situation where I
> can avoid using Common.css altogether so I think there should be a way to
> turn the module off. I don't know what happens if the common.css is empty,
> I will try that out.
>
> Regards,
> Nischay Nahata
>
>
> On Fri, Jul 20, 2018 at 12:04 AM Bartosz Dziewoński 
> wrote:
>
>> There is one important reason why we use  instead of
>> …: when the rendered page HTML is cached, e.g. using a
>> caching proxy like Varnish [1] or MediaWiki file cache [2], then if we
>> used …, you would have to purge every page on the wiki
>> before changes to MediaWiki:Common.css would actually take effect,
>> because the CSS would be embedded in the cached HTML.
>>
>> Using  means that it only takes as long as it takes the cached
>> resource to expire in the users' browsers. (By default, they are set to
>> expire after 5 minutes.)
>>
>> If you don't have caching enabled, then of course that wouldn't matter –
>> but also, if you don't have caching enabled, then that is probably a
>> much worse performance problem than not embedding the styles :)
>>
>> [1] https://www.mediawiki.org/wiki/Manual:Varnish_caching
>> [2] https://www.mediawiki.org/wiki/Manual:File_cache
>>
>> --
>> Bartosz Dziewoński
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Add modules=site.styles inline

[Nischay Nahata]

Thanks for the reply.

I do use the file cache and yes, there could be performance issues with
purging too many problems at once. But again there's a situation where I
can avoid using Common.css altogether so I think there should be a way to
turn the module off. I don't know what happens if the common.css is empty,
I will try that out.

Regards,
Nischay Nahata


On Fri, Jul 20, 2018 at 12:04 AM Bartosz Dziewoński 
wrote:

> There is one important reason why we use  instead of
> …: when the rendered page HTML is cached, e.g. using a
> caching proxy like Varnish [1] or MediaWiki file cache [2], then if we
> used …, you would have to purge every page on the wiki
> before changes to MediaWiki:Common.css would actually take effect,
> because the CSS would be embedded in the cached HTML.
>
> Using  means that it only takes as long as it takes the cached
> resource to expire in the users' browsers. (By default, they are set to
> expire after 5 minutes.)
>
> If you don't have caching enabled, then of course that wouldn't matter –
> but also, if you don't have caching enabled, then that is probably a
> much worse performance problem than not embedding the styles :)
>
> [1] https://www.mediawiki.org/wiki/Manual:Varnish_caching
> [2] https://www.mediawiki.org/wiki/Manual:File_cache
>
> --
> Bartosz Dziewoński
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Add modules=site.styles inline

[Nischay Nahata]

Hi all,

It seems the Common.css on my website is pretty small but Resource Loader
loads it using a  tag in the head. I have read that it will be better
to instead inline the styles or even load them later.

What is the right way to go about this?
Any suggestions are welcome.


Also see
https://developers.google.com/speed/docs/insights/OptimizeCSSDelivery

Regards,
Nischay Nahata
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit as a shared community space

[Nischay Nahata]

I think there's a lot of misunderstanding on this whole thing.

The issue pointed out was that the CoC makes a false feeling of protection
by being in extensions that are developed outside WMF's technical spaces.
That is if I had an issue with an extension's maintainer WMF would refuse
to help as it wasn't in WMF's technical spaces as per the CoC.

This has probably been interpreted as maintainers are against CoC. However,
if the CoC.md file were to claim that the authors support a specific Code
of Conduct it would probably be fine.

Also I would like to note that I have immense respect and thanks for the
WMF devs for their hard work on maintenance on all of these extensions.


Regards,
Nischay Nahata


On Sat, Jun 9, 2018 at 11:58 PM Brian Wolff  wrote:

> Taking a step back here...
>
> I agree with you in principle...but
>
> Shared spaces imply that occasionally disputes are going to arise as to
> what belongs in a repo. If we dont have a fair method of resolving such
> disputes (/my way or the highway/ is not fair), then this model is not
> going to work.
>
> --
> Brian
>
> On Saturday, June 9, 2018, Brion Vibber  wrote:
> > I'd just like to apologize for dragging the other thread into this one
> and
> > being overly personal and failing to assume good faith.
> >
> > That was a failing on my part, and not good practice.
> >
> > Please if you respond further to this thread, treat only the narrow issue
> > of ownership / maintainership expectations and where/how we should be
> more
> > clear on it.
> >
> > Further discussion on people's motives about the code of conduct will
> > likely not be productive for anyone on this thread.
> >
> > My apologies to all; I should do better. You all deserve better.
> >
> > -- brion
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?

[Nischay Nahata]

It did sound like a threat given that no policy has been framed around
this, but I am glad to know that it was not your intent.

Also, its strange that someone can just remove someone else's code review
just like that on gerrit, add their own review and merge a patch.


Regards,
Nischay Nahata


On Fri, Jun 8, 2018 at 3:46 PM Antoine Musso  wrote:

> On 08/06/2018 06:33, Nischay Nahata wrote:
> >  I think that advertising the COC might still have been in "good faith",
> > though it should have been done with a mail to the project owners.
> >
> > But what I find very objecting is the way the two developers have
> > communicated on the gerrit thread. Both Antoine and Chad (both senior
> devs
> > that we used to look up to) behaved in a rather dictatorish manner which
> is
> > not even seen around profit making companies. Neither cared to explain
> and
> > discuss on the issue, while Yaron was trying his best to.
>
> Hello,
>
> I disagree with the dictatorship manner, or I would just have force
> merged my own patch. I was more waiting for feedback from the repository
> owner and engage in a conversation.
>
> I don't have an opinion about the CODE_OF_CONDUCT.md beside that it has
> been added on all mediawiki repositories hosted on Gerrit and that it
> became the de factor standard on GitHub.  I just happened to notice the
> file was missing and for sack of consistency proposed a change to
> restore it.
>
>
> About my comment on Gerrit:
>
> | Well then can we just archive this repository please?
>
> I was reacting to Yaron comment about development happening somewhere else:
> | @Ladsgroup - not all of the development of this software is done on
> gerrit.wikimedia.org (actually, very little of it is).
>
> With the hasty conclusion on my side that: if the development is not on
> Gerrit and Yaron doesn't want the COC.md file, he should be free to move
> to a different hosting place.
>
> In restrospective, I got how that could sound as a threat to arbitrarily
> delete the repository.  *Yaron I apologize*, that never has been my intent.
>
> One sure thing, I am quite happy the topic get raised to wikitech-l
> which has a much larger audience than a single Gerrit change.  We will
> see what the outcome happens to be.
>
> cheers,
>
> --
> Antoine Musso
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?

[Nischay Nahata]

The right place for COC related stuff is probably on the Gerrit user
interface.

On Fri, Jun 8, 2018, 11:48 AM Daniel Zahn  wrote:

> On Thu, Jun 7, 2018 at 11:40 PM, Max Semenik 
> wrote:
>
> > My personal opinion is twofold:
> >
>
> I agree with Max here. The CoC applies anyways whether the file is in the
> repo or not
> because Wikimedia infrastructure is being used.
>
> But we should not make it mandatory to keep a copy of this file in each and
> every repo.
>
> I don't see how "not having the file
> is against the CoC itself" because it certainly doesn't say anything about
> that, in that regard Yaron
> is correct.
>
> --
> Daniel Zahn 
> Operations Engineer
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Can/should my extensions be deleted from the Wikimedia Git repository?

[Nischay Nahata]

 I think that advertising the COC might still have been in "good faith",
though it should have been done with a mail to the project owners.

But what I find very objecting is the way the two developers have
communicated on the gerrit thread. Both Antoine and Chad (both senior devs
that we used to look up to) behaved in a rather dictatorish manner which is
not even seen around profit making companies. Neither cared to explain and
discuss on the issue, while Yaron was trying his best to.


Regards,
Nischay Nahata


On Fri, Jun 8, 2018 at 9:49 AM MZMcBride  wrote:

> Yaron Koren wrote:
> >That's how it went until two days ago, when Antoine Musso submitted a
> >patch for my Site Settings extension (I don't know why that one
> >specifically), re-adding the file. I rejected the patch, on the same
> >grounds as before, but another developer, Chad Horohoe, overrode me and
> >merged it in. That led to a discussion featuring Antoine, Chad, a few
> >other WMF developers, and me, which you can find here:
> >
> >https://gerrit.wikimedia.org/r/#/c/437555/
> >
> >Some of the (unbelievable) highlights:
> >
> >- From Antoine: "Well then can we just archive this repository please?"
> >
> >- From Chad: "Yeah no that's not how it works. If it's being hosted on
> >gerrit.wikimedia.org, it needs a CoC file. If you object to that, you can
> >find hosting elsewhere."
>
> It was really inappropriate for Chad to hastily and forcefully merge this
> change.
>
> MZMcBride
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Proposal for a developer support channel

[Nischay Nahata]

I being a MediaWiki developer see this as a great step forward. Currently
there are too many channels, where the information is all scattered around.

Finding help seems impossible at times on IRC. Mailing lists are difficult
to follow. For search I use a Google so it kind of works, but the archives
are difficult to comprehend. Discourse sounds like a great alternative.

I would also ask if there's a possibility to import content from other
places to the new Discourse site, if that's not too much to ask(fingers
crossed).

On Nov 19, 2017 8:43 PM, "Federico Leva (Nemo)"  wrote:

> If the proposal is triggered by technical problems at [[mw:Project:Support
> desk]], a simple solution is to make it a wikitext page.
>
> As for the "one place" argument, https://xkcd.com/927/ applies.
>
> Federico
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Questions over usage of ObjectCache

[Nischay Nahata]

Thanks for responding Brion. Hopefully this has highlighted something that
is fundamentally misunderstood with the caching code. For the short term
maybe we could use better documentation, and the long term would be a fix
on the task you have created.

Anyways I am now using CACHE_DB :)

Regards,
Nischay

On Apr 4, 2017 12:29 AM, "Brion Vibber" <bvib...@wikimedia.org> wrote:

I've filed a task in phabricator to follow up in case there's any surprises
with the proposed fix. :) https://phabricator.wikimedia.org/T162077

-- brion

On Mon, Apr 3, 2017 at 11:52 AM, Brion Vibber <bvib...@wikimedia.org> wrote:

> On Mon, Apr 3, 2017 at 12:56 AM, Nischay Nahata <nischay...@gmail.com>
> wrote:
>
>>
>> I have been trying to add certain rate limiting actions for my
extension's
>> API and noticed that it doesn't work with $wgMainCacheType set to
>> CACHE_NONE
>>
>> This is because  User::pingLimiter()
>> uses ObjectCache::getLocalClusterInstance() to store the current rate
>> limit
>> counts.
>>
>> Is this the expected behavior? Looks pretty deceitful to me
>> as $wgMainCacheType is assumed to define the cache type but is actually
>> disabling a core functionality like rate limiting and maybe few others?
>>
>
> I'm pretty sure this one's my fault -- at the time it was added we didn't
> expect the rate limit feature to be used in a minimal configuration
without
> an object cache configured, and it ended up being kind of kept that way
> through the years.
>
> I would recommend probably changing this:
> $cache = ObjectCache::getLocalClusterInstance();
> to:
> $cache = ObjectCache::getInstance( CACHE_ANYTHING );
>
> That should set the rate limiter to use the database-backed cache when
> $wgMainCacheType is set to CACHE_NONE, and will use the main cache when
> it's not set off.
>
> -- brion
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Questions over usage of ObjectCache

[Nischay Nahata]

Hi all,

I have been trying to add certain rate limiting actions for my extension's
API and noticed that it doesn't work with $wgMainCacheType set to CACHE_NONE

This is because  User::pingLimiter()
uses ObjectCache::getLocalClusterInstance() to store the current rate limit
counts.

Is this the expected behavior? Looks pretty deceitful to me
as $wgMainCacheType is assumed to define the cache type but is actually
disabling a core functionality like rate limiting and maybe few others?



Regards,
Nischay Nahata
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Engaging student devs with another outreach event like GSoC, GCI

[Nischay Nahata]

On Mon, Nov 7, 2016 at 10:00 AM, Cyken Zeraux <cykenzer...@gmail.com> wrote:

> Nischay makes a good point with the disconnect between education and
> Mediawiki.
>
>
What I meant was: getting to know about GSoC and WMF is hard, compared to a
summer internship at a company which comes to campus. I think GSoC is a
good (in my case was better) alternative to interning at a corporate.



> A contributing factor to this disconnect is that Mediawiki isn't at all
> convenient for educators to get up and running. Thats just the software
> stack. Add ontop of that knowing how to install good extensions, such as
> Visual Editor and the Math extension, and you end up with a pile of sysop
> work that most educators just can't spend the time on. Commercial wiki
> hosters aren't particularly profitable and don't offer these features,
> either.
>
> I was working on a project that could resolve some of these problems, but
> Mediawiki is not made in a fashion that would make this maintainable
> between versions, and in the end would still require a decent amount of
> sysop work.
>
> This would be outside of getting students to code, but if Wikimedia wants
> to help solve the disconnect, hosting a wiki farm that is pre-loaded with
> features educators want, and allowing them to easily create wiki's for free
> (with an .edu email), would certainly do it. Add ontop of that a
> documentation wiki that is a lot more focused on those features, and how to
> properly use them, and you've got a two in one punch.
>
>
>
I like this idea. This would actually help Wikimedia's mission of
generating more knowledge available to all and also add more editors (Profs
currently author lot of content on their self managed sites, which could be
instead be a wiki on this farm).



>
>
>
> On Sun, Nov 6, 2016 at 9:43 PM, Nischay Nahata <nischay...@gmail.com>
> wrote:
>
> > Hi all,
> >
> > My 2 cents.
> >
> > I think GSoC or Wikimedia and schools/colleges don't reach out to each
> > other in a proper manner. This leads to late and limited discovery of
> GSoC
> > (only some students will know mostly when they stalk their seniors
> > profile). So I think there has to be an effort to reach out to students
> > early on, let them know about this programme, etc. This can be done by
> > approaching through the current/past students and maybe the faculty.
> >
> >
> > Secondly, I agree with Yaron that projects should be proposed by mentors.
> > So we need more time from mentors for sure. I was lucky to have mentors
> who
> > had enough time to discuss the project with me and help me while
> executing
> > it. On the other hand when I was working for WMF as a contract developer,
> > WMF engineers didn't have enough time to review my code (not blaming them
> > though).
> >
> >
> > Lastly, I will talk about sticking with a project or the community. Most
> of
> > these college students will go for a full-time job and it can be
> difficult
> > to contribute. If they are still not in the final college year you can
> have
> > them as contract developers (as was in my case) and maybe full-time
> > developers later on.
> >
> >
> > Regards,
> > Nischay Nahata
> >
> > On Mon, Nov 7, 2016 at 7:01 AM, Yaron Koren <ya...@wikiworks.com> wrote:
> >
> > > Hi Tony,
> > >
> > > Well, I still think there might be easier ways of getting students to
> > stick
> > > with Wikimedia/MediaWiki over the long term - one obvious idea is to
> pay
> > > students who had useful projects to maintain or complete those
> projects,
> > > post-GSoC - but nevertheless, if you're willing to put in the work to
> > > create a WMF outreach/mentorship program, I support you; I'm sure any
> > such
> > > effort is better than nothing.
> > >
> > > -Yaron
> > >
> > > On Fri, Nov 4, 2016 at 10:59 AM, Tony Thomas <01tonytho...@gmail.com>
> > > wrote:
> > >
> > > > Hey Yaron,
> > > >
> > > > On Thu, Nov 3, 2016 at 5:34 PM, Yaron Koren <ya...@wikiworks.com>
> > wrote:
> > > >
> > > >> But I hope that there's a better solution for it other than
> > essentially
> > > >> requiring potential students to become detectives, trying to find
> > > >> interesting coding challenges that no one has proposed for GSoC etc.
> > > Maybe
> > > >> the solution is for you and others to do this work yourself -
> talking
> > to
> > > >> MW/WMF developers to find more tasks and drum up enthusiasm amon

Re: [Wikitech-l] Engaging student devs with another outreach event like GSoC, GCI

[Nischay Nahata]

Hi all,

My 2 cents.

I think GSoC or Wikimedia and schools/colleges don't reach out to each
other in a proper manner. This leads to late and limited discovery of GSoC
(only some students will know mostly when they stalk their seniors
profile). So I think there has to be an effort to reach out to students
early on, let them know about this programme, etc. This can be done by
approaching through the current/past students and maybe the faculty.


Secondly, I agree with Yaron that projects should be proposed by mentors.
So we need more time from mentors for sure. I was lucky to have mentors who
had enough time to discuss the project with me and help me while executing
it. On the other hand when I was working for WMF as a contract developer,
WMF engineers didn't have enough time to review my code (not blaming them
though).


Lastly, I will talk about sticking with a project or the community. Most of
these college students will go for a full-time job and it can be difficult
to contribute. If they are still not in the final college year you can have
them as contract developers (as was in my case) and maybe full-time
developers later on.


Regards,
Nischay Nahata

On Mon, Nov 7, 2016 at 7:01 AM, Yaron Koren <ya...@wikiworks.com> wrote:

> Hi Tony,
>
> Well, I still think there might be easier ways of getting students to stick
> with Wikimedia/MediaWiki over the long term - one obvious idea is to pay
> students who had useful projects to maintain or complete those projects,
> post-GSoC - but nevertheless, if you're willing to put in the work to
> create a WMF outreach/mentorship program, I support you; I'm sure any such
> effort is better than nothing.
>
> -Yaron
>
> On Fri, Nov 4, 2016 at 10:59 AM, Tony Thomas <01tonytho...@gmail.com>
> wrote:
>
> > Hey Yaron,
> >
> > On Thu, Nov 3, 2016 at 5:34 PM, Yaron Koren <ya...@wikiworks.com> wrote:
> >
> >> But I hope that there's a better solution for it other than essentially
> >> requiring potential students to become detectives, trying to find
> >> interesting coding challenges that no one has proposed for GSoC etc.
> Maybe
> >> the solution is for you and others to do this work yourself - talking to
> >> MW/WMF developers to find more tasks and drum up enthusiasm among
> potential
> >> mentors - essentially what you did before, but now as an administrator
> and
> >> not a potential student.
> >
> >
> > Thank you for the trust Yaron, but here we are talking not only about new
> > tasks being up in Phabricator for students to charge upon, but to
> increase
> > the quality of students itself before they start working on the project.
> > Performance report of a student in that kind of a program even can make
> it
> > easy for a mentor to better evaluate his/her proposal (considering past
> > contributions matter). More than that, this would be one good option for
> > post-GSoC students to still stick with the community too - as they can
> > either participate, or even be mentors again.
> >
> > Yeah - we are trying to solve actually two problems here - (a) better
> > community code review and codebase aware students before GSoC (b) making
> > students stick back with Wikimedia after they complete their project.
> >
> > Thanks,
> > Tony Thomas <https://www.mediawiki.org/wiki/User:01tonythomas>
> > Home <http://www.thomastony.me> | Blog <https://tttwrites.wordpress.com/
> >
> > | ThinkFOSS <http://www.thinkfoss.com>
> >
> >
>
>
> --
> WikiWorks · MediaWiki Consulting · http://wikiworks.com
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] VE plugin related questions

[Nischay Nahata]

Hi all,

I have been working on a small VE plugin that provides the functionality of
adding SMW annotations. I am mostly done with the script but need to
understand some minor coding practices for VE plugins to complete it. Would
appreciate some help on these questions.

When the script makes some changes to the document model, sometimes the
Save button stays greyed out. Is there a way I should trigger the save
button to become active? Or maybe I am doing something in the wrong way.

The undo doesn't seem to automatically work for my code, what's the best
way to develop that functionality?

I have a couple more doubts, but these are the major ones right now.
Here's my code if needed, its a mess right now and needs lot of
refactoring, etc

https://en.wikipedia.org/wiki/User:Nischayn22/veSMW.js

Thanks and regards,
Nischay Nahata
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] I'm leaving the Wikimedia Foundation

[Nischay Nahata]

Hey Sumana,

I would like to say all the best in your future endeavors and say a big
Thank You for mentoring me (a lot of which wasn't even part of your job).
A lot of credit behind my small successes are attributed to you :)

Let me know how to stay in touch.

On Fri, Sep 12, 2014 at 9:39 PM, Sumana Harihareswara suma...@wikimedia.org
 wrote:

 I write this email with regret to let you know that I've decided to leave
 the Wikimedia Foundation after nearly four years working here, and that my
 last day will be 30 September.

 I go into my reasoning and plans in this personal blog post:
 http://www.harihareswara.net/sumana/2014/09/12/0

 I'm grateful for what I've learned here and will take these lessons
 wherever I go. And I've made many friends here; thank you. I'll remain
 [[User:Sumanah]] in any volunteer work I do onwiki. Quim Gil will be the
 person to contact for any loose threads I leave behind; still, if you have
 questions for me, the next two weeks would be a good time to ask them.

 best,
 Sumana Harihareswara
 was Volunteer Development Coordinator, then Engineering Community Manager,
 now Senior Technical Writer
 Wikimedia Foundation
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Cheers,

Nischay Nahata
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Abandoning -1 code reviews automatically?

[Nischay Nahata]

Some of my changes sitting there are a few month old.

Maybe removing such changes first will reduce the -1 changes to a greater
extent and help us get a clearer idea?


On Wed, Apr 9, 2014 at 9:09 PM, Liangent liang...@gmail.com wrote:

 I have some changesets where I uploaded a reworked patchset several weeks
 or even months after an original -1 was given...

 Anyway a changeset can be easily renewed by rebasing it, but the side
 effect is that all existing -1's get flushed. If people start to use this
 method to extend the period, it's not something good...


 On Wed, Apr 9, 2014 at 11:25 PM, Jon Robson jdlrob...@gmail.com wrote:

  Yes yes yes please!
 
  I've been manually doing this in mobile with a short friendly note saying
  if the owner wants to resubmit it they can feel free to at a later date.
 My
  gerrit is just a spam queue right now.
 
  Just to clarify - if someone submits a patch then says 1 month later via
  comment I still want to work on it do we abandon it for the time being or
  keep it open?
  On 9 Apr 2014 08:08, Quim Gil q...@wikimedia.org wrote:
 
   In relation to our discussion about code review metrics at
   http://korma.wmflabs.org/browser/gerrit_review_queue.html
  
   I just learned that OpenStack has a policy to abandon automatically
  reviews
   sitting in -1 during more than one week:
  
   https://bugzilla.wikimedia.org/show_bug.cgi?id=63533#c1
  
   Maybe one week is too tight for the reality of our project, but what
  about
   2-4 weeks?
  
   Brad and others said last week that they were not interested in code
  review
   queue metrics mixing pending -1 reviews. Maybe the solution is not to
  tweak
   the metrics, but to effectively abandon those changesets automatically?
  
  
   --
   Quim Gil
   Engineering Community Manager @ Wikimedia Foundation
   http://www.mediawiki.org/wiki/User:Qgil
   ___
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org
   https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Cheers,

Nischay Nahata
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Just noticed GitBlit

[Nischay Nahata]

Was trying to play with a bug, googled
'AbuseFilterHooks::onUploadVerifyFile'
and it returned the following as the top result [1]. That was the diff of
the commit which introduced the bug.

Awesome!


[1]
https://git.wikimedia.org/commitdiff/mediawiki%2Fextensions%2FAbuseFilter.git/3c5a074881ed77a46fdb87a5800d57ba232a5226


On Fri, Jun 7, 2013 at 1:43 AM, Platonides platoni...@gmail.com wrote:

 On 06/06/13 07:21, Daniel Friesen wrote:

 Side topic, anyone want to voice their bikeshed opinions on their
 favorite the different ways of disambiguating a / inside urls for
 various types of web UIs to repositories:

 - Rejecting slash in repository names /.../mediawiki-core/... (ie:
 GitHub :/)
 - Urlencoding the slash /.../mediawiki%2Fcore/...
 - Appending a .git to the end of the name /.../mediawiki/core.git/...
 - Wrapping it in syntax/.../{mediawiki/core}/.**..
 - Escaping it /.../mediawiki\/core/...


 Accept the longest substring.



 __**_
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Cheers,

Nischay Nahata
nischayn22.wordpress.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Loading MediaWiki from some script

[Nischay Nahata]

http://www.mediawiki.org/wiki/File:Mediawiki-vagrant-screenshot.png

Does this help?


On Wed, May 22, 2013 at 10:17 PM, Jeroen De Dauw jeroended...@gmail.comwrote:

 Hey,

 I hacked up something extremely evil which is now working for my usecase:
 http://pastebin.com/WcT1MPNv

 Clearly this is far from ideal since my code should not know about MW
 internal at all, it should just include some entry point file.

 One fun thing I had to do was stuff all local variables in the global
 vraibles list, since some setup files are assuming they are run in global
 scope, and some are assuming they are in the same scope as the other files.
 Since my script is not getting executed in global scope, it is sort of hard
 to load these files in global scope :)

 So if someone could create a working solution that has an evilness level of
 less then 9000, I'd be very happy.

 Cheers

 --
 Jeroen De Dauw
 http://www.bn2vs.com
 Don't panic. Don't be evil.
 --
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Cheers,

Nischay Nahata
nischayn22.in
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Ideating on GSOC project : Mobilize Wikidata

[Nischay Nahata]

At first glance this looks too big a project for GSoC.


On Tue, Apr 9, 2013 at 1:12 PM, Pragun Bhutani pragu...@gmail.com wrote:

 Hi,

 I plan to propose a GSOC project through Wikimedia this year, based around
 the idea of mobilizing Wikidata. I'd like to share my understanding of the
 problem and gain some feedback on that, as well as some more input from the
 community.
 *
 *
 *Problem at hand:*
 *
 *
 Unlike Wikipedia, which displays information as mainly text, WIkidata
 presents information in the form of a grid of divs. While the
 MobileFrontend extension prints a mobile friendly version of Wikipedia,
 there needs to be a separate extension for Wikidata.

 This extension needs to be tailored to print these grids instead of text
 and lay them out in a way that's suitable for a mobile device.

 Additionally, the design should allow the addition of/should include 'edit'
 functionality tailored to suit a mobile device.

- Has there been any previous work done on this front that I could refer
to?

 I look forward to receiving your feedback.

 Thanks,
 Pragun Bhutani
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Cheers,

Nischay Nahata
nischayn22.in
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] A new project - Wikicards

[Nischay Nahata]

Wow! That looks like an amazing proposal even in its inception.
With more refinement it will have great potential.


On Sun, Apr 7, 2013 at 9:41 PM, Paul Selitskas p.selits...@gmail.comwrote:

 Indeed. We have a Universal Language Selector for 3rd party websites
 already. This one would be super-duper great. This is where Wikidata
 can play its part as well!

 As for images, we have already a PageImages extension in all wikis,
 and we have Wikidata, where item properties may point to images.

 On Sun, Apr 7, 2013 at 7:05 PM, Petr Bena benap...@gmail.com wrote:
  On first sight I was like WTF is he proposing.
 
  Then I read your proposal and it sounds very nice. I hope you will be
  able to make it happen.
 
  On Sun, Apr 7, 2013 at 4:58 PM, Gaurav Chawla grvi...@gmail.com wrote:
  Hello,
 
  I am Gaurav Chawla, an undergraduate student at IIT Roorkee, India.
  I am applying for this year's Google Summer of Code as a developer for
  Wikimedia. For the past few days, I have been researching about any new
  improvement or extension in funtionality that can be introduced to this
  awesome wiki and finally came up with this idea: WikIcards - small
  information cards.
  I have drafted a project proposal with full description of WikIcards and
  also a sample structure of it at
 http://www.mediawiki.org/wiki/User:Grv99
 
  I have also filed it as an extension request (Bug 46970) at
  https://bugzilla.wikimedia.org/show_bug.cgi?id=46970
 
  I request you to go through this new project and give your suggestions
 and
  feedback. You can give the feedback on the bug report. Alternatively,
 you
  can also add your suggestions at Suggestions section near the end of
 the
  project proposal page. Please comment on its feasibility too.
 
  Hoping for a good response.
 
  Thank you.
 
  Regards,
  Gaurav Chawla
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l



 --
 З павагай,
 Павел Селіцкас/Pavel Selitskas
 Wizardist @ Wikimedia projects

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Cheers,

Nischay Nahata
nischayn22.in
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] whatcanidoforwikipedia.org

[Nischay Nahata]

I think such a website attracts new contributors more easily than
mediawiki.org can. Later when it points to MW for most stuff the
contributor gets used to it :)


On Sun, Apr 7, 2013 at 11:34 PM, Quim Gil q...@wikimedia.org wrote:

 On 04/07/2013 09:23 AM, Yuvi Panda wrote:

 On Sun, Apr 7, 2013 at 9:47 PM, Quim Gil q...@wikimedia.org wrote:

 Why not doing exactly the same but on mediawiki.org directly? All the
 effort
 put on promoting a brand new site could be put instead in promoting
 mediawiki.org in a new, fresh way.


 I think there's a slight misunderstanding.


 I don't think so  :)  but it's fine. No stop energy.


  If you see
 http://whatcanidoformozilla.**org http://whatcanidoformozilla.org, it
 doesn't have much *original*
 content by itself - it just links back to an appropriate page on
 mozwiki. This one will also be the same - it will just link back to
 appropriate mediawiki.org pages.


 Yes, yes. We could argue about the tactics of creating own sites for each
 activity as opposed to build on top of your current platform but there is
 actually little point in doing so.

 Please continue with your initiative but document / discuss in your
 preferred destination under Project:New contributors

 This will help us being all in sync


  And if the pages are not good enough,
 I'll try improve them (or poke people into doing that).


 This is the big part of the work. And related to this: improving
 mediawiki.org homepage and Developer Hub to reflect all the opportunities
 for contribution you are describing.


 --
 Quim Gil
 Technical Contributor Coordinator @ Wikimedia Foundation
 http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil

 __**_
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Cheers,

Nischay Nahata
nischayn22.in
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GSoC 2013 guidelines??

[Nischay Nahata]

On Sun, Mar 10, 2013 at 5:27 PM, Tejas Nikumbh tejasniku...@gmail.comwrote:

 I created a bugzilla account but the process of going through the code and
 fixing bugs seems cryptic. Any resources you can provide which can aid me
 in understanding the process? A video which shows the process or some
 documentation perhaps?


Have you already gone through the process of how to be a hacker?
http://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker

Not a hacker who breaks things of course :)


 On Fri, Mar 1, 2013 at 5:06 AM, Quim Gil q...@wikimedia.org wrote:

  On 02/28/2013 03:14 PM, Bartosz Dziewoński wrote:
 
  On Fri, 01 Mar 2013 00:02:16 +0100, Quim Gil q...@wikimedia.org
 wrote:
 
   Our default recommendation to newcomers has been to try to fix a bug
 from
 
 
  From?
 
 
  Er... sorry (multitasking with just one brain has these things):
 
  https://www.mediawiki.org/**wiki/Annoying_little_bugs
 https://www.mediawiki.org/wiki/Annoying_little_bugs
 
 
 
  Quim probably wanted to link the list of bugs marked as 'easy':
  https://bugzilla.wikimedia.**org/buglist.cgi?quicksearch=%**
  21easy%20-%21patch-in-gerrit
 https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=%21easy%20-%21patch-in-gerrit(here
 I'm also excluding ones with a patch pending). :)
 
 
  Yes, also linked at the URL above.
 
 
  --
  Quim Gil
  Technical Contributor Coordinator @ Wikimedia Foundation
  http://www.mediawiki.org/wiki/**User:Qgil
 http://www.mediawiki.org/wiki/User:Qgil
 
  __**_
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 



 --
 Tejas Nikumbh,
 Third Year Undergraduate,
 Electrical Engineering Department,
 IIT Bombay.
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Cheers,

Nischay Nahata
nischayn22.in
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Query performance - run code faster, merge code faster :-)

[Nischay Nahata]

I found EXPLAIN (http://dev.mysql.com/doc/refman/5.0/en/using-explain.html)
pretty useful during my project; rather than theories it shows
the exact way the query is being resolved and if the indexes are being used
rightly.

On Thu, Mar 7, 2013 at 6:06 AM, Sumana Harihareswara
suma...@wikimedia.orgwrote:

 If you want your code merged, you need to keep your database queries
 efficient.  How can you tell if a query is inefficient? How do you write
 efficient queries, and avoid inefficient ones?  We have some resources
 around:

 Roan Kattouw's

 https://www.mediawiki.org/wiki/Manual:Database_layout/MySQL_Optimization/Tutorial
 -- slides at
 https://commons.wikimedia.org/wiki/File:MediaWikiPerformanceProfiling.pdf

 Asher Feldman's
 https://www.mediawiki.org/wiki/File:MediaWiki_Performance_Profiling.ogv
 -- slides at https://www.mediawiki.org/wiki/File:SQL_indexing_Tutorial.pdf

 More hints:
 http://lists.wikimedia.org/pipermail/toolserver-l/2012-June/005075.html

 When you need to ask for a performance review, you can check out
 https://www.mediawiki.org/wiki/Developers/Maintainers#Other_Areas_of_Focus
 which suggests Tim Starling, Asher Feldman, and Ori Livneh.  I also
 BOLDly suggest Nischay Nahata, who worked on Semantic MediaWiki's
 performance for his GSoC project in 2012.

 --
 Sumana Harihareswara
 Engineering Community Manager
 Wikimedia Foundation




-- 
Cheers,

Nischay Nahata
nischayn22.in
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Reminder about the best way to link to bugs in commits

[Nischay Nahata]

On Mon, Mar 4, 2013 at 7:06 AM, Quim Gil q...@wikimedia.org wrote:

 fwiw this is not a discussion about Gerrit features but about git commit
 and code contribution good practices in general. There is plenty of
 literature out there.


  I also prefer it in the header. The bug report is the best description :)


 A bug report is supposed to describe a problem while the title of a commit
 message is supposed to describe the solution implemented.

 Plus you are limited to 50 chars. The bug number will take 5, that leaves
 you less than 45.

 Plus quite frequently a bug is fixed through more than one commit, and
 still you are supposed to explain in each commit message what you are doing
 in that commit.



I like to know about the problem before the solution implemented, that
saves me some time to think what solutions could be possible.
But that doesn't mean it always have to be in the header. It matters from
the point of view, looking like a bug fixer you are more concerned with bug
numbers while other people are concerned about what is implemented.

But what I find more important is see the bug numbers in the Gerrit 'view',
its easy to find the change for a particular bug being solved. Having a
separate column (as Erik suggested) for that would be the best solution :)




  Is it not possible for Gerrit to search if its in the header?


 Is this helpful?

 status:merged message:yourString

 http://stackoverflow.com/**questions/14409413/searching-**
 gerrit-by-commit-messagehttp://stackoverflow.com/questions/14409413/searching-gerrit-by-commit-message



  Tools should be coded around people. Not the other way around.


 Agree. A 100% human readable commit message title describing what a commit
 does feels more human than Fixes Bug 12345 + truncated bug description


  Is there another software project that uses the summary line
 in a similar way to MediaWiki?


 That was the best question of this thread. I have done some research, and
 the guidelines I found mentioning the inclusion of bug numbers in commit
 messages pointed all to a specific bug line after the commit description
 and an empty line - which is in line with our guidelines. Gerrit and other
 Git tools understand that line as metadata and you can do good things with
 it (as we are on our way of doing between Gerrit and Bugzilla):

 OpenStack Git Commit Good Practice
 https://wiki.openstack.org/**wiki/GitCommitMessageshttps://wiki.openstack.org/wiki/GitCommitMessages

 Chromium - Contributing code
 http://www.chromium.org/**developers/contributing-codehttp://www.chromium.org/developers/contributing-code

 Qt - Introduction to Gerrit
 http://qt-project.org/wiki/**Gerrit-Introductionhttp://qt-project.org/wiki/Gerrit-Introduction

 GNOME - a guide to writing git commit messages
 http://blogs.gnome.org/danni/**2011/10/25/a-guide-to-writing-**
 git-commit-messages/http://blogs.gnome.org/danni/2011/10/25/a-guide-to-writing-git-commit-messages/

 EGit - Contributor Guide
 http://wiki.eclipse.org/EGit/**Contributor_Guidehttp://wiki.eclipse.org/EGit/Contributor_Guide

 Gerrit Code Review - Contributing
 https://gerrit-review.**googlesource.com/**Documentation/dev-**
 contributing.htmlhttps://gerrit-review.googlesource.com/Documentation/dev-contributing.html

 Proper Git Commit Messages and an Elegant Git History
 http://ablogaboutcode.com/**2011/03/23/proper-git-commit-**
 messages-and-an-elegant-git-**history/http://ablogaboutcode.com/2011/03/23/proper-git-commit-messages-and-an-elegant-git-history/


 --
 Quim Gil
 Technical Contributor Coordinator @ Wikimedia Foundation
 http://www.mediawiki.org/wiki/**User:Qgilhttp://www.mediawiki.org/wiki/User:Qgil

 __**_
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Cheers,

Nischay Nahata
nischayn22.in
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Reminder about the best way to link to bugs in commits

[Nischay Nahata]

On Sat, Mar 2, 2013 at 3:16 AM, Chad innocentkil...@gmail.com wrote:

 Hi,

 This is a friendly reminder to everyone about the preferred way to
 link to bugs in your commit messages. When you include them as
 part of the footer, they are indexed and are thus searchable. For
 example:

 
 Fixing some weird bug

 More explanation
 Blah blah blah.

 Bug: 1234
 Change-Id: Ia90.
 

 So when you do this, you're able to search for bug:1234 via Gerrit.
 By doing this, you're also removing it from the first line (which was
 our old habit, mostly from SVN days), providing you more space to
 be descriptive in that first line.


I also prefer it in the header. The bug report is the best description :)

Is it not possible for Gerrit to search if its in the header? or make it so


 -Chad

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Cheers,

Nischay Nahata
nischayn22.in
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gsoc 2013 guidelines

[Nischay Nahata]

On Tue, Feb 26, 2013 at 9:59 PM, Yuri Astrakhan yuriastrak...@gmail.comwrote:

 Atul, one of the fun projects that has been sitting on my backburner is to
 implement errors and warnings localization for the Web API. The project
 would involve some planning, figuring out translation framework, and later
 - converting all API modules and extensions to use it. As a result, all
 clients, including mobile, will be able to report errors to the users in
 their native language. I am not sure how GSOC supervision functions, but I
 will definitely be involved with the implementation.

 This is slightly bigger than a bug fix, but should be fairly independent
 from everything and will give you good exposure into internals as well as
 javascript and other  clients.



I think this is a potential 'good' project itself. There are also small
tasks associated that the applicant can learn from, say properly handle
the errors and warnings in an extension that doesn't already do it.


 On Tue, Feb 26, 2013 at 11:20 AM, Atul Agrawal adi.md...@gmail.com
 wrote:

  @Waldir:working on the link you sent me.I will notify you if I need any
  help
 
  @Quim:While I will love to work under a project and be guided .It will be
  great if you can suggest some beginner level project and  I can work with
  someone or by my own.
  I will like to solve arithmetic bugs,logical bugs,deadlock situation and
  teamworking bugs.
  And one more thing as mediaWiki documentation is so vast, how will I know
  in which specific area I have to develop my skills so that I will able to
  get the idea as well as solve it which will be proposed for gsoc 2013?Do
 I
  need to contact the mentors?
 
  Thanks for being so helpful.
 
  Atul
 
 
 
  On Tue, Feb 26, 2013 at 9:13 PM, Quim Gil q...@wikimedia.org wrote:
 
   On 02/26/2013 01:23 AM, Atul Agrawal wrote:
  
   Thanks a lot.Will try to fix bugs.But what knowledge should I have to
  fix
   bugs?knowing php is sufficient?Till now I have read this page(
   Developing_Extensionshttp://**www.mediawiki.org/wiki/Manual:**
   Developing_extensions
  http://www.mediawiki.org/wiki/Manual:Developing_extensions
   .If
   you can share the documents one should read before fixing bugs,I will
 be
   highly obliged.
  
  
   We have many different software projects, and what to read depends pon
   what bugs you want to fix.
  
   Why not choosing first a project or a bug that interests you, and then
   learn about the pieces involved as you try to fix it?
  
   We can help you find a first bug. What is your area of interest?
  
  
   --
   Quim Gil
   Technical Contributor Coordinator @ Wikimedia Foundation
   http://www.mediawiki.org/wiki/**User:Qgil
  http://www.mediawiki.org/wiki/User:Qgil
  
   __**_
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org
   https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  
 
 
 
  --
  Atul Agrawal
  B.E Mechanical
  BITS PILANI Goa Campus
  Mobile:+91-81491-95049
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Cheers,

Nischay Nahata
nischayn22.in
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Disambiguation features: Do they belong in core or in an extension?

[Nischay Nahata]

Hey,

Just wanted to bring in few points.
If its in core it would be easy tackle bug [1] (note the votes it has) and
more that may come up.

Somewhat related, I think MediaWiki should automatically create
disambiguation pages [2].

[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=3483
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=44704
On Wed, Jan 16, 2013 at 10:40 PM, Richardguk richardg...@yahoo.com wrote:

 Nicolas Vervelle nvervelle at gmail.com writes:

  My own preference would be to have this in the core for several reasons.
 [...]

 Yes, the core code already handles disambiguation pages specially in some
 ways (Special:Disambiguations, MediaWiki:Disambiguationspage). But it
 treats them as exceptional cases - a bit of a hack.

 Proposal:

 A fundamentally more robust and flexible way to handle disambiguation
 pages would be to move them all into their own namespace.

 For example, http://en.wikipedia.org/wiki/Bow and
 http://en.wikipedia.org/wiki/Bow_(disambiguation) could both redirect to
 http://en.wikipedia.org/wiki/Disambiguation:Bow

 This would make it much more consistent with the ordinary wikipage
 functions and internationalization, as well as making it easy to
 programmatically identify disambiguation pages without affecting the
 database schema.

 Though there would initially be some upheaval as pages were moved in bulk,
 the result would be stabler.

 One drawback is that dab pages from all namespaces would end up in the new
 Disambiguation namespace. So,
 http://en.wikipedia.org/wiki/Portal:Football
 would redirect to
 http://en.wikipedia.org/wiki/Disambiguation:Portal:Football
 That is not a major problem, as it is easy to identify pages beginning with
 Disabiguation:Portal: etc, though it makes it harder to list mainspace
 dabpages (they would have to be identified by eliminating valid namespace
 prefixes from the pagename). A similar cross-namespace shadow hierarchy
 already exists at Template:Editnotices/Page/ for edit notices.

 After the initial bulk creation, a bot would need to check for new dab
 pages
 that needed moving into the dab namespace, and for new pages in the dab
 namespace that lacked a redirect in the relevant non-dab namespace.
 Alternatively, the need for separate redirect pages could be obviated if
 MediaWiki automatically redirected browsers when a corresponding
 dab-namespace exists (but this would be a departure from the existing
 practice of having all redirects as editable wikipages).

 Individual wikis would be free to opt out of the new approach.


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Cheers,

Nischay Nahata
nischayn22.in
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Time class in MediaWiki?

[Nischay Nahata]

On Sunday, December 30, 2012, Brion Vibber wrote:

 On Sat, Dec 29, 2012 at 6:41 AM, Nischay Nahata 
 nischay...@gmail.comjavascript:;
 wrote:

  I could find a method to covert a timestamp into the user preferred
  timezone in the Language class; Looks like the wrong place to me.
  Is there any other way (think global function) to convert to the user's
  timezone and preferred format?
 

 Date formatting is language-based, so the date formatting functions do
 indeed live in Language. It's also based on user preferences, which makes
 it a bit of an odd fit, but it's a legit localization thing. :)

 Elsewhere in the code, timestamps are passed around in timezone-independent
 formats based on UTC.

 Also, is there any common script to do this in JS?
 
  With reference to bug 43365
 

 I'm not sure if we have full localization for dates in JS...


Thankfully to the i18n team it seems to be in development now; as per
comment
https://bugzilla.wikimedia.org/show_bug.cgi?id=38079#c5

...but you can use the browser's built-in support. You won't get the same
 formatting, and it may not match the user's *time zone preference* in
 MediaWiki...

 eg

 https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Date/toLocaleString

 -- brion
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org javascript:;
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Cheers,

Nischay Nahata
nischayn22.in
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Time class in MediaWiki?

[Nischay Nahata]

Hi,

I could find a method to covert a timestamp into the user preferred
timezone in the Language class; Looks like the wrong place to me.
Is there any other way (think global function) to convert to the user's
timezone and preferred format?
Also, is there any common script to do this in JS?

With reference to bug 43365
-- 
Happy Holidays,

Nischay Nahata
nischayn22.in
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit reviewer-bot

[Nischay Nahata]

Hi,

I just received an email from this bot, unfortunately that was undesirable.
Its not necessary to cc the original author of a patch when adding a
reviewer, so is the case
when adding a reviewer manually.

On Friday, December 28, 2012, Merlijn van Deen wrote:

 Hello all,

 To add to the great work by Ori and Jon, I have my own recent pet
 project to announce: Reviewer-bot, which adds reviewers to any new
 changes uploaded to Gerrit.

 The basic idea is as follows:
   1) reviewer-bot listens to Gerrit's events stream
   2) a contributor uploads a new change (only the first patchset is
 reacted upon)
   3) reviewer-bot checks http://www.mediawiki.org/wiki/Git/Reviewers
 to see which reviewers would like to be added to new changes
   4) reviewer-bot adds the reviewers to the change

 Obviously, it's still in it's infancy, so it will probably crash every
 now and then. However, please try it by adding your gerrit username to
 the Reviewers page!

 Of course, I also have the obligatory 'Fork me on github!'-notice: the
 code is available at https://github.com/valhallasw/gerrit-reviewer-bot
 .

 I hope that, together with the RSS-based approach by Ori and the daily
 digest-approach by Jon, this will help to improve the Gerrit
 experience - especially for new developers!

 Best,
 Merlijn

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org javascript:;
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Cheers,

Nischay Nahata
nischayn22.in
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] GreenSMW (GSoC)

[Nischay Nahata]

Hi,

Its been a wonderful time working on SemanticMediaWiki this summer
as part of my Google Summer of Code project GreenSMW.
While most of the planned milestones have been reached, I am still working
on more improvements to SMW after GSoC. I have a written a self-evaluation
of my project [1]

SMW 1.8 is likely to be released soon with all my work :)

[1] http://greensmw.wordpress.com/2012/08/21/pencils-down/

-- 
Cheers,

Nischay Nahata
nischayn22.in
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] midsummer updates from GSoC students?

[Nischay Nahata]

On Thu, Jul 5, 2012 at 7:48 PM, Sumana Harihareswara
suma...@wikimedia.orgwrote:

 Akshay Chugh on the Convention Extension:
 http://lists.wikimedia.org/pipermail/wikitech-l/2012-June/061362.html
 (looks like the Wikimania 2013 organizers are working with him to make
 it work for them!)

 Ashish Dubey on realtime collaborative editing:
 http://ashishdubey.info/blog/2012/7/5/realtimeve-first-demo.html (new
 demo!)

 Aaron Pramana on the watchlist: http://mw-watchlist.tumblr.com/

 Nischay Nahata on SMW optimization: https://greensmw.wordpress.com/


 I'd love to hear more from:

 Robin Pepermans on Incubator:
 https://gerrit.wikimedia.org/r/#/q/owner:SPQRobin,n,z

 Platonides on the native uploading app:
 http://thread.gmane.org/gmane.org.wikimedia.wikilovesmonuments/2641/

 Harry Burt on TranslateSVG:
 https://www.mediawiki.org/wiki/Extension:TranslateSvg/2.0

 Ankur Anand on UploadWizard:
 https://gerrit.wikimedia.org/r/#/dashboard/144

 Suhas Rao, on OpenStackManager:

 https://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/suhasmonk/1

 Robin, Platonides, Harry, Ankur, and Suhas: please reply to this thread
 with updates on how you've been doing.  If you're running into any
 obstacles, please speak up!

 --
 Sumana Harihareswara
 Engineering Community Manager
 Wikimedia Foundation

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l



Hi,
A small update on the progress of the project GreenSMW (optimization of
Semantic Mediawiki).

I have been working in baby steps all the time such that SMW is always in a
working condition, most
of my commits have been on the storerewrite branch and now to be merged
with branch master; Its
planned to be into the next release of SMW. Here's a list of things I have
worked on:

   1. Implemented hash check before updating db - this significantly
   reduces the page write times on a SMW wiki.
   2. Fixed table properties - enables separate tables for highly used
   properties and thus reduces db access time.
   3. Refractored parts of SQLStore - this made the code a lot cleaner and
   maintainable for further tasks
   4. DB sharding - using separate tables for properties of different
   tables (not using multiple servers).
   5. UnitTests - tests for SMW's core functionality.
   6. Redefined tables for Booleans (reduced memory usage) and String type
   (removed size limits).

Experiences:
Having two mentors has been a plus point for me; both Jeroen and
Markus have been very helpful.
And though some tasks of the project took more time than I had anticipated
before, with new dependencies
getting identified I could make up for them by writing UnitTests for SMW
(Jeroen had proposed this
as another potential GSoC proposal). I also write tests whenever I am stuck
waiting for a code review.

-- 
Cheers,

Nischay Nahata
http://nischayn22.in
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Suggestions for tasks for new contributors during hackathon

[Nischay Nahata]

On Fri, Jun 22, 2012 at 2:13 AM, Asheesh Laroia li...@asheesh.org wrote:

 Hey all wikitech peeps,

 In helping organize the upcoming Wikimania DC Hackathon, I wanted
 to ask if there are particular categories of work that people with
 fairly limited experience could do that would have a meaningful impact.

 For example:

 * Updating extensions to work with the latest version of MediaWiki

 * Testing extensions so that we can update mediawiki.org pages about
  the extension's compatibility with different MediaWiki revisions

 * Converting user scripts into Gadgets

 * Convert templates into Lua (but seems lower-impact than some of
  the above because Lua scripts aren't deployed very many places yet)

 * (Only applicable to attendees who mntain an extension) Teaching
  maintainers how to move extensions from the wiki into things that
  live in Git and are updated through Gerrit

 I'm especially interested in tasks where there's a lot of work to do --
 that way, people can be given lots of hands-on things to do that can
 provide practice to help people be more comfortable with tools like git
 and gerrit, or more comfortable with the MediaWiki hooks, or where the
 task gives people a reason to install MediaWiki on their own machine.
 Additionally, it's important the task meaningfully contributes to the
 project, so people feel the value of what they're doing.

 I expect that we'll get a lot of people with some PHP experience but who
 have little experience with, say, Git and Gerrit.

 Also, if you'll be at the Wikimania DC 2012 Hackathon and want to help
 mentor people through any of these, reply as well.

 Other ideas welcome. I'll be collating these over the next few days,
 and then trying to pick the ones with the highest probable impact based
 on the attendees. One warning: this is intended just as a research
 question for now. I can't promise that I'll focus a portion of the
 hackathon on your particular suggestion. But I do aim to stay in touch
 as the planning progresses.

 -- Asheesh.

 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Since you mentioned Updating extensions to work with the latest version of
MediaWiki 
I think writing unit tests for extensions could be very useful and fairly
easy to learn.

-- 
Cheers,

Nischay Nahata
http://nischayn22.in
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Planning for the future: prepare high resolution icons and images in your code

[Nischay Nahata]

On Tue, Jun 19, 2012 at 5:19 AM, Brion Vibber br...@pobox.com wrote:

 On Mon, Jun 18, 2012 at 4:43 PM, Platonides platoni...@gmail.com wrote:

  My concern are images inside articles, where a big screen user will want
  |500px but a small screen one |120px.
  Maybe we should move to a size specification dependant on the
 clientWidth.
 

 That's really a separate issue, which is that a large portion of image uses
 in content should probably be changed; trade hardcoded sizes for galleries
 and priority markers, perhaps. And of course replace the crappy old
 link-to-image-page with a sensible click-to-zoom.


I had once talked about this (click-to-zoom) feature on wikimedia sites in
irc.
Wikipedia could have something similar to sites like Facebook or Google+
where the images float over the page.
I have tried an extension
FancyBoxThumbshttp://www.mediawiki.org/wiki/Extension:FancyBoxThumbs
which
enables such a feature, with some enhancements it can be more awesome.
-- 
Cheers,
Nischay Nahata
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Green SMW Progress

[nischay nahata]

Hi everyone,

Firstly, thanks to all Mentors and Sumana for accepting my GSOC proposal.
It has been a pleasure working with the Wikimedia and SMW community so far
for me and I look forward to an awesome summer.

Secondly, Markus and I have started working on the project. We have made
some priority assignments to our goals and as per that we will be making
some changes to the Database access code(make it cleaner) first and than
look into other performance degradation issues. While we do the first part
feedback/ideas/suggestions on performance degradation issues with SMW are
most welcomed. Most of the ideas we discussed has been documented at
SQLStore_Update http://semantic-mediawiki.org/wiki/SQLStore_Update.

I am also maintaining a blog http://greenswm.wordpress.com specifically
for this project; I write most of my activities there. Comments/feedback
are most welcomed on my blog http://greenswm.wordpress.com/ or on the
project talk-page
Nischayn22/Gsochttps://www.mediawiki.org/wiki/User_talk:Nischayn22/Gsoc

Thanks

-- 
Nischay Nahata
B.tech 3rd year
Department of Information Technology
NITK,Surathkal
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] GSOC - Green SMW

[nischay nahata]

Hi,

Thanks for the reply, I hope it will be useful to you (if got selected).
Could you please link to your site?

On Fri, Apr 6, 2012 at 9:01 PM, Thomas Fellows thomas.fell...@gmail.comwrote:

 Hey Nischay!

 Really excited about your proposal - we use an incredibly large SMW
 instance (something like 36million pages, ~167805989 triples and another
 30mil coordinates).  As you might expect, it doesn't really work. Granted,
 we haven't moved to a triple store yet, but after the work you're doing we
 might have a chance to take another look at it.  Good luck!

 -Tom.

 On Wed, Apr 4, 2012 at 12:33 AM, nischay nahata nischay...@gmail.comwrote:

 Hi,

 I am participating in GSOC'12 with my proposal for Green SMW [1].
 This proposal is about reducing the carbon footprint of SMW , in other
 words it will enhance the performance of SMW significantly.
 All the details are on [1], suggestions to improve or comments are most
 welcome.

 I have also been contributing to MW with my new Extension:AllTimeZones
 [2],
 comments to that are welcomed as well.
 My other contributions to MW are listed here [3].


 [1]www.mediawiki.org/wiki/User:Nischayn22/Gsoc
 [2]www.mediawiki.org/wiki/Extension:AllTimeZones
 [3]www.mediawiki.org/wiki/User:Nischayn22

 --
 With Regards

 Nischay Nahata
 B.tech 3rd year
 Department of Information Technology
 NITK,Surathkal
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l





-- 
With Regards

Nischay Nahata
B.tech 3rd year
Department of Information Technology
NITK,Surathkal
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] GSOC - Green SMW

[nischay nahata]

Hi,

I am participating in GSOC'12 with my proposal for Green SMW [1].
This proposal is about reducing the carbon footprint of SMW , in other
words it will enhance the performance of SMW significantly.
All the details are on [1], suggestions to improve or comments are most
welcome.

I have also been contributing to MW with my new Extension:AllTimeZones [2],
comments to that are welcomed as well.
My other contributions to MW are listed here [3].


[1]www.mediawiki.org/wiki/User:Nischayn22/Gsoc
[2]www.mediawiki.org/wiki/Extension:AllTimeZones
[3]www.mediawiki.org/wiki/User:Nischayn22

-- 
With Regards

Nischay Nahata
B.tech 3rd year
Department of Information Technology
NITK,Surathkal
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Mediawiki-l] New Plugin for Extension:ConfirmEdit - RFC

[nischay nahata]

Thanks for the tips

Open Source is particularly helpful to students, we get to learn,
contribute and also work on real stuff (things that get deployed).
I am having a wonderful experience.

On Wed, Mar 21, 2012 at 3:20 AM, Antoine Musso hashar+...@free.fr wrote:

 Learning from mistakes is the best way to train your brain in fixing
 problems. Open source will help you improve your skill:

 1) publish your code to the public
 2) get flaws exposed
 3) Understand what is wrong
 4) Fix / amend / rewrite
 5) Repeat

 If the idea end up being totally wrong. Rethink about it, talk about it
 with other people and submit some new code :-)

 In the end:

 Profit!!!  (please donate to your favorite foundation)


 I for one like the idea of making Captcha more meaningful to humans and
 harder to solve by bots.

 Congrats on your first extension!


 --
 Antoine hashar Musso


 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
With Regards

Nischay Nahata
B.tech 3rd year
Department of Information Technology
NITK,Surathkal
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] New Plugin for Extension:ConfirmEdit - RFC

[nischay nahata]

Hi,
I have made a Captcha plugin for ConfirmEdit called MCQ (Multiple Choice
Questions)
Below is the usage of it

sample Captcha:
Pick the correct Option Number
We pray to 1.Time 1.God 3.Lion 4.Tomato ?
 Answer 2

Why Beneficial ?
* Bots don't have common sense
* No Images so loads faster
* Most Important - Good support for i18n
* Further plans to let the user just select the right option rather
than typing text


It is currently hosted on github at https://github.com/nischayn22/MCQCaptcha
.

This is my first Extension/Plugin so it may have many faults, my apologies
for that.
Please leave your comments
-- 
With Regards

Nischay Nahata
B.tech 3rd year
Department of Information Technology
NITK,Surathkal
IRC nick- nischayn22
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] API - Edit by IP not by user

[nischay nahata]

  I'm not sure what version the dutch one has.


You can check version using Special:Version

-- 
With Regards

Nischay Nahata
B.tech 3rd year
Department of Information Technology
NITK,Surathkal
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Mediawiki-l] New Plugin for Extension:ConfirmEdit - RFC

[nischay nahata]

Thanks for your replies, I realize this is a faulty plugin right now for
following reasons

* 25% probability
* securing the questions and answers

I will see if I can remove them, again this is my first plugin and I am
trying to learn
so my apologies :)

-- 
With Regards

Nischay Nahata
B.tech 3rd year
Department of Information Technology
NITK,Surathkal
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Plugin for Extension:ConfirmEdit - RFC

[nischay nahata]

On Tue, Mar 20, 2012 at 8:43 AM, Mono monom...@gmail.com wrote:

 Typing an answer might work.


Thanks for the suggestion, I will make the following changes

* Typing of answer, rather than option number (let me know if bots can
crack this too?)
* Securing the questions and answers (How can we still translate the
questions  answers?)

-- 
With Regards

Nischay Nahata
B.tech 3rd year
Department of Information Technology
NITK,Surathkal
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] New Plugin for Extension:ConfirmEdit - RFC

[nischay nahata]

However this is what is done in QuestyCaptcha, Is there any way we can add
localisation to Questions on QuestyCaptcha?

On Tue, Mar 20, 2012 at 9:04 AM, nischay nahata nischay...@gmail.comwrote:



 On Tue, Mar 20, 2012 at 8:43 AM, Mono monom...@gmail.com wrote:

 Typing an answer might work.


 Thanks for the suggestion, I will make the following changes

 * Typing of answer, rather than option number (let me know if bots can
 crack this too?)
 * Securing the questions and answers (How can we still translate the
 questions  answers?)

 --
 With Regards

 Nischay Nahata
 B.tech 3rd year
 Department of Information Technology
 NITK,Surathkal




-- 
With Regards

Nischay Nahata
B.tech 3rd year
Department of Information Technology
NITK,Surathkal
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] gsoc proposal idea -enhancing CentralNotice Extension

[nischay nahata]

Surely will remind you after 19th.
Bon Voyage

On Sat, Mar 10, 2012 at 1:15 AM, Ryan Kaldari rkald...@wikimedia.orgwrote:

 Hello Nischay,
 I'm on vacation for the next week, but please remind me to follow up on
 this after I get back on the 19th. At first glance these sound like good
 ideas, and I would probably be available to mentor on their development.


-- 
With Regards

Nischay Nahata
B.tech 3rd year
Department of Information Technology
NITK,Surathkal
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] gsoc proposal idea -enhancing CentralNotice Extension

[nischay nahata]

Hi,

I am a 3rd year Engineering student from India, I have a few project ideas
for gsoc, one is regarding enhancement of the extension : CentralNotice.

Here is a brief outline of the new features suggested

   - Enabling Editing of Banners
   - Campaigns notifying only specific targeted users - For example,
   Requesting Users with more than 100 edits in wikipedia but no activity in
   last 3 months to continue contributing.
   - Simpler UI-based Banner creation
(herehttp://lists.wikimedia.org/pipermail/wikitech-l/2012-March/058765.htmlis
a discussion regarding the same)
   - More Statistics
   - putting namespace specific notices
   - Making the extension more usable with respect to needs of Wikimedia
   and Non-Wikimedia needs

However I think many more such features can be added.I would request Ryan
Kaldari and Brion Vibber to give their feedback regarding this proposal.
I also request Srikanth, who suggested many features mentioned here to
comment if I have missed out any important features.

-- 
With Regards

Nischay Nahata
B.tech 3rd year
Department of Information Technology
National Institute of Technology, Surathkal
IRCnick- nischayn22
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Images in wikipedia

[nischay nahata]

When using wikipedia and clicking on an image it opens up on a new page.
Wouldn't it be nice if it just scaled-up on the same page using JS. Is
there an extension there for this? and if yes why not implemented on
wikipedia?

--
With Regards

Nischay Nahata
B.tech 3rd year
Department of Information Technology
NITK,Surathkal
irc-nick nischayn22

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Images in wikipedia

[nischay nahata]

On Mon, Feb 27, 2012 at 3:39 PM, Strainu strain...@gmail.com wrote:
 There used to be a user script for that. I have a modified version at
 http://ro.wikipedia.org/w/index.php?title=Utilizator:Strainu/picture_popups.js
 if you're interested in the code.

 I can't seem to find the original version and I haven't used the
 script in a long time, so there are no guarantees it still works.

 Strainu

I am not looking for any code. But want to know why is it not
implemented in en.wikipedia.org?


-- 
With Regards

Nischay Nahata
B.tech 3rd year
Department of Information Technology
NITK,Surathkal

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l