I was privileged to attend the GSOC mentor summit last week at the Google Campus in Mountain View, actually nowadays the summit takes place at the Google tech corners in Sunnyvale which is a short ride away, it was a great opportunity to meet, talk and learn from several folks plus eating lots of amazing food, in fact there was a huge table the entire weekend with all kinds of chocolate you can imagine. I would recommend everybody that hasn’t been there to attend it when they have the opportunity.
I personally enjoyed a session where we got to talk about ways to leverage tools like Github and Jira to improve workflows, code review and the issue curation process to simplify things for contributors especially the new ones, I think we’re headed in the right direction with the auto formatter, coveralls and codacy.
I also talked to one of the lead developers for Mifos and it was humbling to hear him say that they’ve been trying to model their community based on that of OpenMRS which is an indication that there is several things we’re doing right.
Below are some of the other things that stood out for me;
A session on susi, an open source AI API and solution, they actually have a demo web client you can play with, I know there have been discussions in the past on decision support in the OpenMRS community and what came to my mind was that we could leverage tools like this in case we eventually added decision support, of course several other things that would need to be addressed come to mind like where to obtain the start up medical assistant (source of information) that the AI system can initially use and then enrich as it learns.
There was also one on xwiki which is a programmable wiki, I was thinking that an implementation can actually use this to build forms, I got the impression that one can tie it to OpenMRS in order to collect data from the forms created with it since it has a powerful form designer and then we would save and process the collected data in the OpenMRS instance.
Of course it was great to meet up with @k.joseph and @harsha89 at the summit, I don’t know if there is something they would like to add from the sessions they attended.
The summit was pretty interesting and inspiring, i attended divers sessions this time round to learn other ventures in IT out of curiosity. I was humbled knowing of other starting organisations who are genuinely being inspired by OpenMRS while discussing with Edward Cable the CEO of Mifos, 2 of the sessions i attended had something to do with videography where i met with the VLC LAN, etc (video organisations), while in a hardware session lead by the apertus.org guys, i was inspired to tryout writing code for some small pieces of e-health hardware, these guys are creating a free and open technology for professional cinema and film production and in that session in particular they demoed one of their GSoC project where they designed an adjustable voltage converter for the apertus AXIOM Beta camera system.
However all that may not be too beneficial to some folks here. I attended other sessions
one was a question whether Open source can solve health care, we discussed efforts that several people are extending in the e-health field such as OpenMRS, Concept Dictionary, FHIR standards, OpenHIE, OpenAPS among others. I was mostly drawn to the OpenAPS.org by their powering of medical devices for personal use, in the same session i learnt of LibreHealth tending to university/research deployments.
In one session some proposal requirements were suggested;
Prior contribution (patch) or proof of concept.
Successful interaction with multiple mentors (through any channel that is used during the project later on).
Openness to requests for changes; for example, young or female mentors have to be respected by a student.
Good behaviour, conduct; honesty.
Clear goals, realistic timeline, alternative goals if project goes better/worse than planned.
For the next GSoC administrators and to us all, here are some student selection points from across the mentoring organisations that attended the summit;
Before Student Applications open (for admins):
Ensure mentors are dedicated
Have backup mentors
Have mentors write up project descriptions
Ensure projects aren’t too hard for students
Have mentors come up with tasks for students to see if they can do the project/learn more about the project
Create email templates for tasks
Ensure tasks for students to do are clearly defined, doable, and relevant for the project
Have a landing page on your website
Include Project descriptions
Rate projects from Easy, Medium, Hard. Specify what that means (ex: Hard projects are ones only Ph.D students could do, or Easy projects can be done by a 2nd year CS student)
Include required skills (ex: programming languages and frameworks)
Make project descriptions clear enough that the project could be understood once someone knows about the project, but vague enough that a student will need to ask questions and poke into the code to learn more about it.
Thought: Don’t list any possible projects as “easy”
Thought: List all projects as “hard”
Thought: Make proposals as hard sounding as possible
One project did not any list publicly mentor information for the projects
ensures mentors do not get unwanted emails
ensure that mentors are interacting with students later in the process who have shown they can put together a solid proposal
many mentors have been stalked in the past
Ensure email templates/google forms are ready for when applications open
After Student Applications open:
When it first opens for all students
One org has a transparent point system for applications
Have a mailing list or IRC/Slack channels just for GSoC for students/mentors to introduce themselves/ask about projects
Have a google form to collect initial information
have a question that shows they’re enthusiastic about the topic area of organization
ex: fav. application of Machine learning
opens up bias for people not comfortable writing in english??
Ask a silly question to get a gauge of their personality
Possible Tasks all interested students do
Tasks could be assigned in the google form or on the “landing page”
learn about the project and the community,
have resources available for this
set up an initial dev environment
have them submit evidence they did this
Have them reproduce a bug
have them submit evidence they did this
make sure they can answer “dumb” questions about the project
have them answer questions that have to do with the reading code
have tasks that ensure they can read code, have a development environment, and write code
Have an event at a designated time where students can meet and talk to mentors
ensure that students open a pull request/fix a bug
For students that have shown they are capable of writing a good proposal
some orgs have video interviews for applicants
gauges interest,enthusiasm, commitment, and technical knowledge
opens up bias for people speaking in English/that are shy??
discuss advanced stage proposals on the public mailing lists
let students know that they can re-negotiate project scope if needed
prioritize communication skills and interactions over actual proposal content
Fedora gives students write access to their wiki when they have earned a certain badge
proposal drafts go on the wiki and get feedback from the community
When the student application deadline is getting closer
let people know if project has many applications and especially qualified applicants, steer them to other projects with less applicants
Don’t take applications seriously that were done at the last second
publicly state this to ward off procrastinators
ensures that applicants have communicated with the community
Remember there are always exceptions (ex: one mentor was in the room that started his app 4 days before the deadline)
find some way to always ensure that last second applicants can be competitive
Otherwise great was an opportunity from OpenMRS to meet with the various GSoC mentoring contacts and our own @wyclif and @harsha89,
Here is a shot we took at first meet-up as this year’s administrators