Thanks the explain in-depth about why storing configuration in articles is a good thing. Keep up the good work. On Aug 26, 2012 2:11 PM, "akshay chugh" chughakshay16@gmail.com wrote:

-1

On Sun, Aug 26, 2012 at 11:34 PM, John Du Hart compwhizii@gmail.com wrote:

...

On Wed, Aug 22, 2012 at 8:40 AM, akshay chugh chughakshay16@gmail.com wrote:

...

6. Parser tags, Magic Words (Variables) and a parser function

parser tags --> <conference>, <page>, <account>, <registration>,<passport>,<author>,<submission>,<event>,<organizer> and

<location>

This is a disgusting way to store data.

-- John

---

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

-- Thanks, Akshay Chugh skype- chughakshay16 irc - chughakshay16(#mediawiki) [[User:Chughakshay16]] on mediawiki.org _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Aug 26, 2012, at 11:04 AM, John Du Hart compwhizii@gmail.com wrote:

This is a disgusting way to store data.

I don't think we need to talk to each other like this.

--- Brandon Harris, Senior Designer, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

Hello Peachey,

Honestly I never got into reading any Coding Conventions or style guide while I was developing code for my extension, but I have been going through them for the past couple of weeks and have been fixing those style issues with my code since. Its only a matter of time before all such issues will be addressed, I am continually working on fixing them. You can go and see my latest patches where you will get a sense of all those issues being taken care into account. I have kept a todo list of all such comments which were posted in my changesets, so before my code is finally ready to be tested or even reaches a point of being presentable it will have all such elements that you are trying to point out here.

On Mon, Aug 27, 2012 at 2:54 AM, K. Peachey p858snake@gmail.com wrote:

During your time in GSoC, what type of things did you mentor explain?

Because i've had a quick peruse of your gerrit change sets and I know they are only minor but I do see a few things that our Coding Conventions cover as well as stylize (which is a script that is can be run)

---

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

MZMcBride wrote:

MediaWiki has participated in several (Google) Summer of Code iterations now (https://www.mediawiki.org/wiki/Summer_of_Code) and I'm wondering how this partnership program is evaluated.

After I posted this, Sumana pointed out that MaxSem has done a great evaluation here: https://www.mediawiki.org/wiki/User:MaxSem/GSoC_analysis.

There's also a good overview of past projects at https://www.mediawiki.org/wiki/Summer_of_Code_Past_Projects.

And, of course, should MediaWiki decide not to participate in Google Summer of Code in 2013, are there other [better] ideas for getting people involved in MediaWiki development?

Perhaps a better model: https://www.mediawiki.org/wiki/UCOSP_Spring_2012?

MZMcBride

Chris McMahon wrote:

Most software projects fail (for some definition of "fail"). Even for highly skilled and highly experienced companies and shops, most software projects fail. I'm not going to look up the Gartner and Forrester and Chaos reports this late on a Monday night, but google away.

GSoC is an investment that is not intended to have a short-term payoff. The fact that ANY GSoC code makes to production is fantastic.

GSoC is an investment in the long term. It is intended to provide real concrete experience to promising students in real environments, including all the frustrations and annoyances that everyone on a software team experiences in the real world all the time. Schools simply do not provide that experience. Some fraction of those participants will take those experiences into the future of software development, to make real improvements, both to code and to process.

Thank you for this. You make some good points.

So I guess it might just be a matter of better managing expectations of all parties involved? The disappointment factor is serious and dangerous, in my opinion. It can be mitigated by setting appropriate expectations for the students involved, the mentors involved, and the end-users involved, many of whom desperately want to see some of these features live.

Furthermore, considering GSoC solely in terms of benefit to Mediawiki/Wikipedia is short-sighted. Take a look at the organizations participating: http://www.google-melange.com/gsoc/projects/list/google/gsoc2012 . What would your opinion be if WMF were not on that list?

Personally, I don't care very much about being a participant for the sake of being a participant (and I imagine many others feel similarly). I think for a lot of people who watch these Summer of Code projects, it _is_ about benefit to MediaWiki/Wikimedia, particularly as getting involved in these projects can detract from already painfully finite mentoring and reviewing resources.

MZMcBride

I think you touch the most important point here. I'm one of the main people who manage GSoC for KDE. KDE is the biggest org taking part in GSoC this year in terms of number of students mentored. In addition we are running our own program (Season of KDE) next to it. So in total I'd say we've mentored about 100 students through these programs this year alone. We didn't get there by accident. You know what the main benefit of GSoC is in my opinion? Getting an organisation into the mindset of mentoring - into the mindset of "yes we need to train new people because they can do awesome things even if they screw up sometimes on the way there".

+1000. I <3 that way of thinking and I'd very much like our community to have the same attitude towards GSoC. We're a community working towards education of the world. Participating in GSoC as a mentoring organization is a right fit.

- Ryan

TL;DR: we're improving at student retention but need to get better at producing something useful at the end of a mentorship period; some suggestions follow.

On 08/28/2012 04:44 AM, Finne Boonen wrote:

On Tue, Aug 28, 2012 at 9:41 AM, Ryan Lane rlane32@gmail.com wrote:

...

...

I think you touch the most important point here. I'm one of the main people who manage GSoC for KDE. KDE is the biggest org taking part in GSoC this year in terms of number of students mentored. In addition we are running our own program (Season of KDE) next to it. So in total I'd say we've mentored about 100 students through these programs this year alone. We didn't get there by accident. You know what the main benefit of GSoC is in my opinion? Getting an organisation into the mindset of mentoring - into the mindset of "yes we need to train new people because they can do awesome things even if they screw up sometimes on the way there".

+1000. I <3 that way of thinking and I'd very much like our community to have the same attitude towards GSoC. We're a community working towards education of the world. Participating in GSoC as a mentoring organization is a right fit.

Agreed.

GSoC imho is not about getting code written but getting people involved in our community. As such we should look and see how many people remain involved after GSoC.

Finne

It has now been three months since the "pencils down" late in late August when GSoC 2012 officially ended. Therefore it's a good time to look at the nine students we accepted to see how many are still involved with MediaWiki, how many of the GSoC projects themselves are anywhere near what their original targets were, and whether we would prefer to try this again next year or go for a different approach to outreach and mentoring.

The answers: * seven of the nine students are still actively working on MediaWiki development. This is better than last year -- at this time last year, only about 2-3 of the eight accepted students remained involved. * one project hit its target (including merge into trunk) and about four others are partially merged into trunk and still have momentum towards completion. This is a little better than last year; about 2 projects from last year are fully merged into trunk and about 1 more is partially merged but there's no momentum towards the finish.

https://www.mediawiki.org/wiki/Summer_of_Code_2012/management reflects how I wanted to run this year's GSoC. I think we did well at "People are more important than code" selection, which is one reason we're doing well at retention. But I failed at ensuring that students were scoping their proposals at about 6 weeks of coding work and dedicating the entire last month of the summer to bugfixing and code review. The proposals usually allotted either no time or about 2 weeks for merging with trunk, pre-deploy code review, and integration. I think smaller scoping would have helped, so in the future, we should simply not accept proposals that do not allot at least a third of the summer to code review and response to code review.

I also failed at staying hands-on enough in ensuring frequent mentor-student communication. Having multiple hands-on mentors who were available to do code review REALLY helps, as we see from Nischay Nahata's success (he is our only student this year who got all his project code merged), and I think that in future years we should mandate that all students have two mentors, each of whom commit to reviewing new patchsets within 2 business days. Students can't afford delays in code review. The WMF is improving how it makes time for its engineers to mentor newer contributors (more on that this week) and that will help with this; we're also growing experienced volunteer developers who are interested in mentoring, so I think a 2-mentors-per-student mandate is doable. We should also mandate twice-weekly voice or videocall meetings and do spot checks to ensure they're happening; multiple students didn't have enough communication with their mentors and were shy about pushing for it.

Now, to discuss future mentoring approaches:

I tried to get us into UCOSP again for fall 2012 and was told they were out of slots, so I'm pushing to get us into UCOSP for spring 2013.

We couldn't muster enough mentors to do Google Code-In well so we aren't doing it this year.

Quim Gil is the administrator for our participation in the Outreach Program for Women, so I'll let him discuss how he wants to manage that and how he'll be setting expectations appropriately. :-) I think mandating two mentors per participant is a very good idea, Quim, what do you think? Also: instead of making newbies write fixed proposals with schedules, these OPW internships can follow broader charters and flex to accommodate students' interests and abilities, and it's easier to rescope iteratively to ensure that something useful gets produced by the end of the three months. The fact that some of the internships will be in marketing or communications will help with this, as it's easier to get fast critique of those deliverables. (Also, participants don't have to be students, so some of them will be more mature!)

And regarding future Google Summer of Code management, Yaron Koren wrote:

So here is my proposal: there should be in place some plan of action, ideally for every project, in case it goes overlong and doesn't get completed in time. That can take several forms: a commitment by the mentor or another experienced developer to finish up the project; a commitment by the WMF to fund the student to finish it, if the student turns out to be serious and it's just a simple lack of time that was the issue; a commitment by the WMF to fund someone else to finish it or just a commitment by the student to finish it themselves, on a volunteer basis. The last of those is tricky, because that tends to be the conclusion at the end of uncompleted projects anyway - the student keeps working on it, but that usually only lasts for a few months before the student's school work and/or regular work get in the way, and then the project often falls by the wayside. A commitment on the WMF and/or mentor side would be the ideal thing - and if there's no such guarantee for a specific project, then that should be taken into consideration when deciding on whether to accept it.

This is worth discussing when we decide whether to apply for Google Summer of Code 2013 (if Google decides to run it again).

Does anyone particularly agree or disagree?

OK, let me try to clarify this issue a bit. I know Akshay understands the concept as we have talked about this for about a week before he even started this project but i guess he is not using the right terms for the message to come across.

Basically what you're asking is "Why use native MW functionality instead of custom DB objects to store data". You might not be asking this but if you would have tried to understand Akshay's concept and if you'd go trough the code and instead of looking for spacing issues took a moment to look at the logic, you'd see this is what you're asking.

And here's my anwser:

1. forward compatibility (upgradability). If your code uses very narrow link to core you need to maintain that link throughout the native code upgrades. By using native concepts of storing and accessing data in the first place your code gets upgraded for you when the native code upgrades. This extension is using a lot of of such basic concepts that can't change radically in a short time without breaking a lot of other extensions out there. If we'd use DB we'd first have to make sure our DB is abstracted and then maintain compatibility when DB schema and it's abstraction evolves. We'd also have to make sure our code is able to install and upgrade using mw installer principles which would mean yet another additional task.

2. core MW functionality. This extension is in fact a way of linking individual pieces of data (in our case articles about a conference, about events, about locations, about people) into one structure, but while still keeping them what they are: an article. We are applying properties to articles that define their purpose and position in this structure and for that we're using page_props table as these are just that ... page properties. As page_props are a in a sense volatile data, as they get rebuilt every time a page gets parsed so the simplest way to achieve concurrency of these properties over page rebuilds is to make sure that they get recreated by the core itself along with other properties and this is done by using a parser tag. There is still some work to be done, to enable editors to do some inline editing of these tags by masking them and by using alternative editor hook principles. But to link back to the question at hand, my counter-question would be "why reinvent core mw functionality by using custom DB objects for storing page properties?"

3. "cost/effect". The parser tag, besides containing parameters needed to establish the right page_props state for a given page, also has a few additional data chunks, that could possibly be put into custom db objects, however as those chunks of data are small and get used rarely and even then in most cases it is only when doing editing trough administrative dashboard, it would be prudent to ask yourself if you can excuse creating that much additional code for so little effect. I failed to see that effect being enough for the cost and that's why i suggested Akshay to not use custom DB objects just to store that.

This extension is still a beta and as such needs some lovin' to get it from this hackish state to a stable release, but by my accounts the core functionality of it is sane.

And as for standards ... I've mentored Akshay the same way i mentored some people locally and the same way i have mentored all of the interns i've had. I've told them to forget about standards when doing test cases and alpha work, remember they exist when doing beta and try to apply most of them when doing releases as it has proven to be a good strategy for getting fresh solutions and not just crappy copy-pasting of stale snippets to get the work done. And also, just as the code, the standards too need be updated once in a while (and that can't happen if you consider them a law at all times). You might "frown upon" certain things at a given moment, but in the next moment that might just become a logical solution for your problem ... so do take into an account it's "flaws", be skeptical about it's validity ... just don't dismiss it too soon.

And John, as i've told you (or at least tried to tell you) on IRC: before understanding why someone does things in a certain way it's impossible to say if it's good or bad (or even disgusting in your case), so please, try to understand before making conclusions.

LP, Jure

On 08/26/2012 08:04 PM, John Du Hart wrote:

On Wed, Aug 22, 2012 at 8:40 AM, akshay chugh chughakshay16@gmail.com wrote:

...

6. Parser tags, Magic Words (Variables) and a parser function

parser tags --> <conference>, <page>, <account>, <registration>,<passport>,<author>,<submission>,<event>,<organizer> and

<location>

This is a disgusting way to store data.