On Wed, Aug 22, 2012 at 8:40 AM, akshay chugh <chughakshay16(a)gmail.com> wrote: This is a disgusting way to store data. -- John

On Aug 26, 2012, at 11:04 AM, John Du Hart <compwhizii(a)gmail.com> wrote: 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(a)gmail.com> wrote: -- Thanks, Akshay Chugh skype- chughakshay16 irc - chughakshay16(#mediawiki) [[User:Chughakshay16]] on mediawiki.org

On 12-08-27 04:10 PM, John Du Hart wrote: See this is also unnecessary. Your original message might have been better stated as Instead, you antagonized Ashkay and didn't get an answer. And now here we are. Wasn't there a thread about conduct? Where did that end up? :) Ashkay, incidentally, I would also love to hear more about why you decided this, if you have a minute to answer! Thanks all, -- Mark Holmquist Contractor, Wikimedia Foundation mtraceur(a)member.fsf.org http://marktraceur.info

MZMcBride wrote: 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>. Perhaps a better model: <https://www.mediawiki.org/wiki/UCOSP_Spring_2012>? MZMcBride

Chris McMahon wrote: 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. 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

+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

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:

Thank you for this summary. It is very useful. Would you mind commenting more on lessons learned about the selection of candidates? We need the right now for https://www.mediawiki.org/wiki/Outreach_Program_for_Women On 11/18/2012 05:17 AM, Sumana Harihareswara wrote: As commented in another thread, I have just drafted https://www.mediawiki.org/wiki/Talk:Mentorship_programs Defaulting to two is ok, but we can be flexible here - in both ways. Sometimes a single mentor can be trustworthy, sometimes not even two will convince us. ;) Just like with candidates, there is no magic formula for mentors (neither for program admins) :) I like a lot your "People are more important than code" meme but we need to find a balance here. I agree that the candidate shouldn't spend much time with formalities like defining whether task X will take exactly 2 or 3 weeks. Still, it is good (for everybody) to go through that exercise before presenting a proposal. It filters those excessively lazy or unskilled and it helps the candidate and the mentor to see whether the generic idea survives a first reality check. Still, your concerns are valid, and I have tried to address them in the list of selection criteria. https://www.mediawiki.org/wiki/Talk:Mentorship_programs#Criteria Good idea. Also included in the selection criteria. -- Quim Gil Technical Contributor Coordinator Wikimedia Foundation