cat /dev/brain

Designing and Building OSAP

Initial Success

Following the advice of Jim "Big Tiger" Remsik, I made the Google Docs Forms that have started OSAP as a service. Thankfully, I have a more manageable way of helping apprentices find mentors than people emailing me directly. Due to those forms working so well, we already have several people paired up to work together. So for the initial success we all have Jim to thank as well as the mentors who signed up to help. Thank all of you.

Designing OSAP

There are two parts to OSAP:

  1. The human interaction involving mentor and apprentice
  2. The website that helps them find each other

Designing Human Interaction

This is something that I have no clue how to do, but I am definitely trying to teach myself about it. Luckily, I have met other individuals through this endeavor with similar ideas and goals who are far more adept at this than I am. I hope to continue a discussion with them and work with them on this end of the project. In short, I do not currently know how to optimize for each pair's effectiveness but I think the following guidlines will help in that:

  • After agreeing to pair on a project discuss your availability and set a first date to work together.

  • Discuss what you want to work on during that first session ahead of time so you can clarify and communicate your goals.

  • Set a time limit on the first session. Provide adequate time for technical difficulties since there is no guarantee there will not be any.

  • Decide on your tools ahead of time. Will you use ssh+vim+tmux+skype or Gobby+Hangouts or something totally different?

  • Walk away from your first session with a set of goals you would like to achieve before the next session.

  • You should probably not pair more than 5 times. Your pair is meant to help you become acquainted and break through any road blocks you run into. In short they're a boost over the fence, not a long-term crutch. Nothing is broken about the apprentice and the apprentice is not ill. There is, perhaps, a bit of an obstacle (like a fence) that they need help over.

    Another way to view it is as the mentor teaching the apprentice to ride a bicycle. There are only so many times the mentor can run along side the bike before the apprentice does not need them and sometimes the pair needs to be forced to disengage.

  • Do awesome stuff. Contributing to Open Source Software is not just submitting pull requests that fix bugs or add new features. Open Source Software is making the documentation for a project better or helping triage issues. Sometimes it is hard for people to just pick up how to do all of that. Mentors need to expect those kinds of requests as well.

Designing the Website

So from the start I wanted a website where apprentices and mentors could sign up and connect with each other. To be entirely clear, the site will probably simply refer to pairprogramwith.me for most of the resources plus whatever recipes mentors/apprentices decide to share with us. The website will also not act as a messaging platform or a calendar service. There are already more than enough of both on the internet and one more is just one more place to miss an important message someone sends to you.

Logging in

There will be (even if not initially) three login (and registration) mechanisms:

  • GitHub
  • BitBucket
  • Twitter

Those signing up to be mentors will be asked to allow use to view their user info and their repositories (obviously not on Twitter). The user info will be used to prefill some of the profile information and the repositories will all be hidden by default. The mentor will select which repositories on which they are comfortable pairing with an apprentice. We will not continuously update your list of repositories. If you want us to recollect them on your behalf then there will be a mechanism to do so.

Apprentices will be asked for no special permissions.

Information we will ask (only required if stated explicitly) from all users:

  • Name (preferrably full)

  • Email address (required)

    The email address will be visible to all users who are registered and logged into the website. Provided my firm statrements above, this will be how users communicate with each other.

  • Location

  • Language preferences

All user profiles will be non-public by default, i.e., no one who has not registered can see this type of profile. All users will have the ability to publicize their membership.

Mentors should expect to be asked for a short biography which will not be required. They will also be able to toggle availability based which will show or hide them from the apprentices. The default state will likely be that they are available but this will be emphasized upon registration. It will also be easy to locate.

Aprentices will not be asked for any extra information. They will, however, have a large button they can press when they feel ready to mentor someone else. Upon clicking it they will be asked to grant us the extra permissions stated above as well as to fill out the extra information described.

Finding a mentor

Apprentices will be able to see all of the mentors that are available. They will also be able to see which projects the mentor contributes or is willing to pair on and where they are located. Some people may prefer to pair in person. After deciding they would like to pair with someone they coordinate (via email) with their mentor when, how, etc. Basically my only role will be maintaining the website.

Ideas to be decided upon

I have wondered if a system for apprentices to rate mentors would be a wise choice. My concern here is that there is room for abuse and this could alienate the mentor. Instead I have been strongly in favor of encouraging an iterative and feedback based system between mentor and apprentice. How to do this in a way that would allow the apprentice to communicate without feeling intimidated is still opaque to me.

Another idea that has floated around in my head has been the ability to ban those who abuse the service or are blatantly disrespectful to others. This again would be quite open to abuse, even if it took some arbitrary number of reports to get someone banned. After Twitter introduced a similar feature that was abused to some vocal minorities, I am quite skeptical of introducing something like this myself, even if I were to micromanage it by hand. All it would take is a small group of social engineers to start reporting people and getting the banned for doing nothing wrong or for having very vocal opinions. At the same time, being able to disable accounts would be quite useful, especially with users being able to register via Twitter. I would rather spam bots not have the ability to scrape the mentors page for email addresses.

Communicate with me

Feedback on this post is always welcome. Feel free to send me an email or a tweet. Further more if this is posted to Reddit, HN or anything similar, let me know so I can address concerns there. I will also update this post with links to those pages. In general though, if I don't know, I won't read the comments and I'll probably be a happier person for it.