Designing and Building OSAP

Mon 09 September 2013 by Ian Cordasco

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.


Starting OSAP

Mon 26 August 2013 by Ian Cordasco

This past weekend was Madison Ruby and it was fantastic. After it finished on Saturday, I went to dinner with some super awesome people and we eventually started discussing open source. A couple of the people at the table expressed concerns and fears about contributing to existing open soure projects ...

read more

Requests 1.2.0

Sun 31 March 2013 by Ian Cordasco

tl;dr dispatch_hook now sends the keyword arguments that were originally sent with the request. Hook authors should modify their hooks to accept them and resend them.

This morning Kenneth published (on PyPI and Crate) requests 1.2.0 which included a lot of very important changes. One, which will ...

read more

Showing bash some love

Sun 06 January 2013 by Ian Cordasco

So in my last post I discussed my pyserv bash function that looks and behaves like a program. I didn't exactly disect it, but I have a different one that I will disect.

Meet my nifty function called sandbox:

sandbox(){
    if [[ -z "$1" ]] ; then
        echo "sandbox: No directory provided ...
read more

One-liners

Mon 26 November 2012 by Ian Cordasco

I'm just going to collect some useful one-liners that I've either made myself or found elsewhere. I think some of these might benefit some people I know, so there may be follow up posts to add more.

What's my IP? (python)

This requires requests but it could ...

read more

Unittests in github3.py

Tue 18 September 2012 by Ian Cordasco

After mostly finishing github3.py[1] I started writing the unittests for the library. I waited until the end because I knew I wanted to test directly against the API. To do that, I needed to make sure I had all the functionality that would return the proper objects to ...

read more

Weirdness in python2

Wed 22 August 2012 by Ian Cordasco

So a friend of mine is learning python and was fooling around in the interactive console. They accidentally ran:

'str' > 19
# But they meant to run
'str' > '19'

Can you guess what that evaluated to? Conventional thought would suggest a TypeError, but in fact that evaluates to True. Odd right ...

read more

A Few Thoughts

Mon 20 August 2012 by Ian Cordasco

I've just had a few things kicking around in my head lately and I thought I'd jot them down.

github3.py

With the exception of paginated calls, github3.py is essentially feature complete but is lacking tests for everything. My plan as of this point in time is ...

read more

github3.py (update)

Thu 02 August 2012 by Ian Cordasco

I previously mentioned my work on github3.py and how I was having trouble creating downloads on GitHub because they use Amazon's S3 service for the uploaded files. What this means is that first you have to "create" the download on GitHub then you have to upload the actual ...

read more

CacheFS + OpenLDAP

Sat 14 July 2012 by Ian Cordasco

A Bit of Background

I haven't mentioned it before, but after graduating from Stevens Institute of Technology, the Computer Science department hired me to work in the Scientific and Research Computing Information Technology (SRCIT) "department". We have approximately 120 desktop client machines with 4,000 users and 9 servers ...

read more