Wikimedia-IN-PUN June 2011

wikimedia-in-pun@lists.wikimedia.org

24 participants
35 discussions

Media Contacts: Pune
by Hisham Mundol 01 Jun '11

01 Jun '11

> Hi All Do any of you have contacts with local media in Pune? Would love to get name of correspondents, name of publication / radio or TV channel as well as email IDs or phone numbers. Could you share these with me and Moka offline? We are looking at providing a diverse mix of media with the opportunity to cover the Wikipedia India Education Program - and the Campus Ambassadors who are associated with this. I'm particularly keen on getting local publications (especially Marathi) and local radio channels. Many thanks Hisham Mundol Wikimedia India Programs skype : hisham.wikimedia gtalk : hmundol(a)wikimedia.org twitter : @mundol

1 0

[OT] Effective mentoring programs
by sankarshan 01 Jun '11

01 Jun '11

In context of the Campus Ambassador Program that is in place/being launched. <http://blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/> I’ve been thinking a lot recently about mentoring programs, what works, what doesn’t, and what the minimum amount of effort needed to bootstrap a program might be. With the advent of Google Summer of Code and Google Code-In, more and more projects are formalising mentoring and thinking about what newcomers to the project might be able to do to learn the ropes and integrate themselves into the community. These programs led to other organised programs like GNOME’s Women Summer Outreach Program. Of course, these initiatives weren’t the first to encourage good mentoring, but they have helped make the idea of mentors taking new developers under their wing much more widespread. In addition to these scheduled and time-constrained programs, many projects have more informal “always-on” mentoring programs – Drupal Dojo and GNOME Love come to mind. Others save smaller easier tasks for newcomers to cut their teeth on, like the “easy hacks” in LibreOffice. Esther Schindler wrote a fantastic article a few years ago documenting best and worst practices in mentoring among different projects. Most mentoring programs I have seen and participated in don’t have a very good success rate, though. In this article, I look at why that is the case, and what can be put in place to increase the success rate when recruiting new developers. Why most mentoring fails Graham Percival, a GNU/LilyPond developer, decided in 2008 to run an experiment. At one point, Graham decided that he would quit the project, but felt guilty about doing so in one go. So he started the “Great Documentation Project” to recruit a replacement documentation team to follow on after his departure. He then spent 12 months doing nothing but mentoring newcomers to get them involved in the project, and documented his results. Over the course of a year, he estimates that he spent around 800 hours mentoring newcomers to the project. His conclusions? The net result for the project was somewhere between 600-900 hours of productivity, and at the end of the year, 0 new documentation team members. In other words, Graham would have been better off doing everything himself. Graham found that “Only 1 in 4 developers was a net gain for the project” – that is, for every 4 apprentices that Graham spent time mentoring, only 1 hung around long enough for the project to recoup the time investment he put into mentoring. A further 1 in 4 were neither gain or loss – their contribution roughly equalled the mentor time that they took up. And the remainder were a net loss for the project, with much more time spent mentoring than the results could justify. The GNOME Women’s Summer Outreach Program in 2006 had 6 participants. In 2009, the GNOME Journal ran a “Where are they now?” follow-up article. Of the 6 original participants, only one is still involved in free software, and none are involved in GNOME. Murray Stokely did a follow-up in 2008 to track the 57 alumni of Summer of Code who had worked on FreeBSD. Of these, 10 students went on to get full commit access, and a further 4 students were still contributing to FreeBSD or OpenBSD after the project. Obey Arthur Liu also did a review of Debian participants in 2008. Of 11 students from 2008 who had no previous Debian developer experience, he found that 4 remained active in the project one year later. >From my own experience as a replacement mentor and administrator in the Summer of Code for the GIMP in 2006, we had 6 projects, most of which were considered a success by the end of the summer, yet of the participating students, none have made any meaningful contribution to the GIMP since. I feel safe in saying that the majority of mentoring projects fail – and Graham’s 1 in 4 sounds about right as an overall average success/failure rate. This begs the question: why? Most mentored projects take too long What might take a mentor a couple of hours working on his own could well take an apprentice several days or weeks. All of the experience that allows you to hit the ground running isn’t there. The most important part of the mentoring experience is getting the student to the point where he can start working on the problem. To help address this point, many projects now require Summer of Code applicants to compile the project and propose a trivial patch before they are accepted for the program, but understanding the architecture of a project and reading enough code to get a handle on coding conventions will take time. It will also take mentor time. It takes longer to teach a newcomer to your project than to do the work yourself, as anyone who has ever had a Summer intern will attest. When you set a trainee task which you estimate to be about 4 hours work, that will end up costing a few weeks of volunteer effort for your apprentice, and 8 to 10 hours mentoring time for you during that time. Obviously, this is a big investment on both sides, and can lead to the apprentice giving up, or the mentor running out of patience. I remember in the first year of Summer of Code, projects were taking features off their wishlists that had not been touched for years, and expecting students new to the project to come in and work full time implementing them perfectly over the course of 12 weeks. The reality that first year was that most of the time was spent getting a working environment set up, and getting started on their task. Mentoring demands a lot of mentors As a free software developer, you might not have a lot of time to work on your project. Josh Berkus, quoted in Schindler’s article, says “being a good mentor requires a lot of time, frequently more time than it would take you to do the development yourself”. According to the Google Summer of Code FAQ, “5 hours a week is a reasonable estimate” for the amount of time you would need to dedicate to mentoring. Federico Mena Quintero suggests that you will need to set aside “between 30 and 60 minutes a day“. When you only have 10 hours a week to contribute to a project, giving up half of it to help someone else is a lot. It is easy to see how working on code can get a higher priority than checking in with your apprentice to make sure everything is on track. Communication issues More mentoring projects fail for lack of communication than for any other reason. Apprentices may expect their mentors to check in on them, while mentors expect apprentices to ask questions if they have any. Perhaps newcomers to the project are not used to working on mailing lists, or are afraid of asking stupid questions, preferring to read lots of documentation or search Google for answers. In the absence of clear guidelines on when and how parties will talk to each other, communication will tend towards “not enough” rather than “too much”. No follow through Many mentoring programs stop when your first task is complete. The relationship between the mentor and the apprentice lasts until the end of the task, and then either the apprentice goes off and starts a new task, with a new mentor, or that is the end of their relationship with the project. I would be really interested to hear how many Summer of Code mentors maintained a relationship with their students after the end of the Summer, and helped them out with further projects. I suspect that many mentors invest a lot of time during the program, and then spend most of their time catching up with what they wanted to do. Project culture In her OSCON keynote in 2009, Skud talked about the creation of a welcoming and diverse community as a prerequisite for recruiting new developers. Sometimes, your project culture just doesn’t match newcomers to the project. If this happens regularly, then perhaps the project’s leaders need to work on changing the culture, but this is easier said than done. As Chris di Bona says in this video, “the brutality of open source is such that people will learn to work with others, or they will fail”. While many think that this kind of trial-by-fire is fine, the will not be the environment for everyone. It is really up to each project and its leaders to decide how “brutal” or forgiving they want to be. There is a trade-off: investing time in apprentices who will contribute little is a waste of time, but being too dismissive of a potential new developer could cost your project in the long run. Mentoring best practices Is all the effort worth it? If mentoring programs are so much hassle, why go to the bother? Mentoring programs are needed to ensure that your project is long-term sustainable. As Graham says in his presentation: “Core developers do most of the work. Losing core developers is bad. Projects will lose core developers.” Do you need any other reason to start actively recruiting new blood? There are a few simple things that you can put in place to give your mentoring program a better chance of success. Small tasks Mentored tasks should be small, bite-sized, and allow the apprentice to succeed or fail fast. This has a number of advantages: The apprentice who won’t stick around, or who will accomplish nothing, has not wasted a lot of your mentor’s time. The apprentice who will stay around gets a quick win, gets his name in the ChangeLog, and gains assurance in his ability to contribute. And the quick feedback loop is incredibly rewarding for the mentor, who sees his apprentice attack new tasks and increase his productivity in short order. Graham implies that a 10 minute task is the right size, with the expectation that the apprentice might take 1 hour to accomplish the task. A ten minute task might even take longer to identify and list than it would to do. You can consider this cost the boot-strapping cost of the mentoring program. Some tasks that are well suited to this might include: Write user documentation for 1 feature Get the source code, compile it, remove a compiler warning, and submit a patch Critique 1 unreviewed patch in Bugzilla Fix a trivial bug (a one line/local change) Of course, the types of tasks on your list will change from one project to the next. Mentoring is management Just as not everyone is suited to being a manager, not everyone is suited to being a mentor. The skills needed to be a good mentor are also those of a good manager – keeping track of someone else’s activity while making them feel responsible for what they’re working on, communicating well and frequently, and reading between the lines to diagnose problems before it’s too late to do anything about them. When you think of it in this way, there is an opportunity for developers who would like to gain management experience to do so as a mentor in a free software project. Continually recruiting mentors is just as important as recruiting developers. Since mentoring takes a lot of time, it’s important that mentors get time off and new mentors are coming in in their place. Pair apprentices with mentors, not tasks An apprentice should have the same mentor from the day he enters the mentoring program until he no longer needs or wants the help. The relationship will ideally continue until the apprentice has himself become a mentor. Free software communities are built on relationships, and the key point to a mentoring program is to help the creation of a new relationship. Mentoring relationships can be limited in time also, 6 months or a year seem like good time limits. The time needed to mentor will, hopefully, go down over this period. Regular meeting times Mentors and apprentices should ensure that there is a time on their calendar for a “one on one” at regular times. How regularly will depend on the tasks, and the amount of time you can spend on it. Weekly, fortnightly or monthly are all reasonable in different situations. This meeting should be independent of any other communication you have with the person – it is too easy for the general business of a project to swallow up a newbie and prevent their voice from being heard. Rands said it well when he said “this chatter will bury the individual voice unless someone pays attention.” Convert apprentices into mentors Never do you understand the pain of the initial learning curve better than when you have just gone through it. The people best suited to helping out newcomers to the project are those who have just come through the mentoring program themselves. This is a phenomenon that I have seen in the Summer of Code. Those students who succeed and stay with the project are often eager to become mentors the following year. And they will, in general, be among the best mentors in the project. Keep track For all involved, it’s useful to have some idea of the issues newcomers have – ensure that documenting solutions is part of what you ask. It’s also useful to know how successful your mentoring program is. Can you do better than the 1 in 4 success rate of LilyPond? Keeping track of successes and failures encourages new mentors, and gives you data to address any problems you run into. Manage the mentors All of this work has overhead. In a small project with 1 or 2 core developers, it’s easy enough to have each core developer take an apprentice under their wing, and co-ordinate on the mailing list. In bigger projects, keeping track of who is a mentor, and who is mentoring who, and inviting new mentors, and ensuring that no-one falls through the cracks when a mentor gets too busy, is a job of itself. If your mentoring program goes beyond more than ~5 mentors or so, you might want to consider nominating someone to lead the program (or see who steps up to do the job). This is the idea behind the Summer of Code administrator, and it’s a good one. Go forth and multiply Developer attrition is a problem in open source, and recruitment and training of new developers is the only solution. Any project which is not bringing new developers up to positions where they can take over maintainership is doomed to failure. A good mentoring program, however, with a retention rate around 25%, organised continuously, should ensure that your project continues to grow and attract new developers. Replenishing your stock of mentor tasks and recruiting new mentors will take effort, and continual maintenance of someone putting in a few hours a week. If you execute well, then you will have helped contribute to the long term diversity and health of your project. -- sankarshan mukhopadhyay <http://sankarshan.randomink.org/blog>

2 1

Introducing Campus Ambassadors to the Pune & India Community
by Hisham Mundol 01 Jun '11

01 Jun '11

Hi Pune / India As you are aware, India Programs has been working on kicking off the Wikipedia India Education Program. As part of this, we received a huge response from hundreds of interested volunteers and we have selected 22 bright, passionate and motivated Campus Ambassadors. They come from an incredibly diverse background - and all have impressed us with their potential. I'm writing to formally introduce the initial set of 22 Pune Campus Ambassadors to you. Their names are (in no particular order) Gurudas Nulkar Gurmeet Singh Arnav Sonara Prateek Saxena Ram Shankar Yadav Kailasam B Seva Panda Arnav Chaudhary Rohit Patnaik Wasim Mogal Deepti Chaudhari Sandeep Pherwani Poonam Deshpande Pallavi Agarwal Mihir Khatwani Kiran Attal Parag Tambe Raghavendra "RG" Rao Sagar Makode Abhishek Suryawanshi Alex James Deepesh Chaudhari As we go along, I'm sure they will need your help and support and advice and guidance and motivation. Do welcome them into your fold as you have warmly welcomed everyone else. (I've marked PJ, Srikeit, Annie & Frank on this mail) Warmest Regards, Hisham Mundol Wikimedia India Programs skype : hisham.wikimedia gtalk : hmundol(a)wikimedia.org twitter : @mundol

2 1

India Campus Program kick-off trip agenda
by Ashwin Baindur 01 Jun '11

01 Jun '11

---------- Forwarded message ---------- From: Hisham Mundol <hmundol(a)wikimedia.org> Date: Wed, Jun 1, 2011 at 9:56 AM Subject: Fwd: [Wikimedia-IN-PUN] Important : WikiPuneri Meetup No 14 - Date changed to 04 Jun 2011 and a special invite to the community To: Ashwin Baindur <ashwin.baindur(a)gmail.com> Cc: Sudhanwa Jogalekar <sudhanwa.com(a)gmail.com>, Annie Lin < alin(a)wikimedia.org>, Frank Schulenburg <fschulenburg(a)wikimedia.org>, PJ Tabit <pjtabit(a)gmail.com>, Srikeit <srikeit(a)gmail.com> can you share the following link with the community because it is now fixed up http://outreach.wikimedia.org/wiki/India_Campus_Program_kick-off_trip_agenda would love it if you could also ask for support from whoever wants to be involved. <http://outreach.wikimedia.org/wiki/India_Campus_Program_kick-off_trip_agenda> *Hisham Mundol* * * *** Wikimedia <http://wikimediafoundation.org/wiki/Home> India Programs<http://meta.wikimedia.org/wiki/Wikimedia_Foundation_-_India_Programs> * * skype : hisham.wikimedia gtalk : hmundol(a)wikimedia.org ** twitter : @mundo *l

1 0

Important : WikiPuneri Meetup No 14 - Date changed to 04 Jun 2011 and a special invite to the community
by Ashwin Baindur 01 Jun '11

01 Jun '11

Hello friends, There is a lot happening in Pune next week. We have a lot of visitors in town who would especially like to interact with the Pune Community. Our help and cooperation has been sought for the Campus Ambassador training event next weekend. Our *MEETUP DATE IS NOW CHANGED FROM 11 JUN TO 04 JUN* *2011 (Saturday)* at 1800 hours at SICSR, Atur Centre, Model Colony. Room No 704. 7th floor. Hisham Mundol, National Program Coordinator, who is leading the Campus Ambassador programme, will be in Pune for a week for masterminding the event. Bishakha Datta, Trustee, will be gracing the event on Saturday. Tinu Cherian, the quintessential Indian outreach activist, will also be coming for and participating in the meet - a rare treat for us. I spoke to Arjuna Rao Chawala and he has promised to confirm attendance by an Indian Chapter representative soon. We have a number of people visiting us from abroad. Frank Schulenburg, Head of Public Outreach and Annie Lin, who leads the Ambassador Program are visiting Pune for the Campus Ambassador training event on 04-05 Jun 2011. We also have P.J. Tabit coming down to India between June 1st and August 21st to support the launch of the Wikipedia India Education Program. PJ is a Campus Ambassador in the US and is on the Ambassador Steering Committee for Wikipedia. We, the Pune community, welcome Frank, Annie & PJ to Pune and hope they have a wonderful stay. We also welcome any members of the Wikimedian community in India from outside Pune who are going to be with us for this event. Do let us know if we can help you in any way. Broadly speaking, the campus ambassadors will be trained on 4th and 5th Jun by the outreach team comprising lndian and foreign Wikipedians. In the evening on Saturday, the campus ambassadors and the outreach team will be present for our meetup.* After the meetup, the Outreach Team has invited the Pune Wikipedia community for a* *SOCIAL EVENING WITH DINNER*. Venue for social evening will be indicated at the meetup. Coming to another issue, the Campus Ambassadors themselves. The first batch of Campus Ambassadors has been selected. To those selected, we say - heartiest congratulations, you will shortly be learning to edit and to evangelise Wikipedia. It is a most challenging task and we assure you of the community's support. We invite you to be part of our community and we promise to help you, guide you and partner you in this extraordinary journey you will undertake. We also know that some other aspirants have not been selected this time round. In most cases, this is due to their lack of Wikipedia skills. To all of them we say - there will be another round of selection coming up in a few months, so have a great heart and wait. The fact that all of you stood tall and came forth means you already belong to the select batch of people who are doers and achievers. We, the Pune community, invite you to join us for this meetup and become part of us. We will help you get the skills to make you ready for the next round of selections. *Many of you all who are interested in becoming Wikipedians are requested to join all of the above :* - http://groups.yahoo.com/group/mr-wiki/ (Marathi Wikipedia Group) - https://lists.wikimedia.org/mailman/listinfo/wikimediaindia-l (Mailing list for Wikimedians in Pune, India) - https://lists.wikimedia.org/mailman/listinfo/wikimedia-in-pun (Mailing list for Wikimedians in Pune, India) *Also please join the following groups on Facebook* - Wikimedia India - WikiPuneri *IMPORTANT*: All those attending the meetup from Pune (excepting those selected for the Campus Ambassador program or those organising the event or visiting from outside Pune) need to confirm attendance so that we can plan accordingly. Send your confirmation to : ashwin.baindur(a)gmail.com with subject : "Attending Pune meetup". Those not attending need not respond. So till then, Au revoir & Namaste, Khuda Hafez and Sat Sri Akal, Jai Hind * * * * * * * * * * * * * * * * * * Ashwin Baindur

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Wikimedia-IN-PUN June 2011