search

Thrillberg / code-together

0 stars 0 forks source link

What features comprise an MVP? #1

Open Thrillberg opened 5 years ago

hovsater commented 5 years ago

This was just some initial thoughts. There are probably a lot of things one could add, but I really want the MVP to be as small as possible. Perhaps the above is too much already.

Thrillberg commented 5 years ago

Register for an account (via GitHub?)

I like this idea! Since basically everyone uses GitHub, this seems like a sensible integration to lean on.

Profile image (Required. I feel a profile image will help humanize the potential pair)

Agreed. Shall we use whatever image the user uses on GitHub?

Define availability (when and for how long)

I see this as an open question. Part of me wants it to be synchronous (ie, you log on when you've got some time and you click a "Match Me!" button and you wait some (hopefully short) period of time to get auto-matched while you wait) but that seems frustrating if we don't have many users so maybe a "calendar"-type feature as you describe would be better (at least to start with).

Define your skill levels (this one I'm not too sure about)

I'm also not sure. Maybe instead of "level" terminology we can let users describe themselves as "learners" and "ambassadors" of certain technologies. So, I could log on as an "ambassador" of Rails and "learner" of Elm and then get matched with people who indicate their willingness to pair with me. Of course, a beginner could erroneously call themselves an "ambassador" but we should probably have some sort of overarching policy of graciousness in which pairs don't take these labels too seriously and are ALL eager to both teach and learn.

Define areas of interest (What are you interested in working on)

Agreed. This could get more interesting/complicated if we have it be about projects and/or languages. I think we should discuss this more.

Matching candidates are notified via an email (contact information available within the email)

Sounds good!

Thrillberg commented 5 years ago

Thanks for enumerating some features @KevinSjoberg! I also wanted to open the discussion up to what special thing this app will offer. It seems to me that we could get kinda sorta what we want by 2 means that don't involve us building anything:

1) A Twitter hashtag (#pairwithme, or something) -- the genesis of this whole thing 2) A Slack group dedicated to people who like to pair with strangers

I think what we make can be better than both of these but I'm interested in exploring in what direction to build. So, to try to be a bit more concrete, we could do any of the following (not necessarily mutually exclusive options):

I'm sure there are many more directions we can go. But I think it's important to figure out which, if any , of the above are appealing to us both so as the app develops we don't find ourselves at odds in terms of how to continue. What do you think? Do some of those potential directions strike you as more interesting/desirable than others?

hovsater commented 5 years ago

Agreed. Shall we use whatever image the user uses on GitHub

That sounds fair. If no profile image exists on GitHub, we should probably navigate the user to a page for uploading an image with a friendly explanation as to why a profile image matters.

I see this as an open question. Part of me wants it to be synchronous (ie, you log on when you've got some time and you click a "Match Me!" button and you wait some (hopefully short) period of time to get auto-matched while you wait) but that seems frustrating if we don't have many users so maybe a "calendar"-type feature as you describe would be better (at least to start with).

I definitely agree with you that synchronous, match me now, behavior would be cool, especially if the number of users grow. Then we could even promote how many are in queue right now. But as you said yourself, I think it's better to begin with a calendar-style approach.

I'm also not sure. Maybe instead of "level" terminology we can let users describe themselves as "learners" and "ambassadors" of certain technologies. So, I could log on as an "ambassador" of Rails and "learner" of Elm and then get matched with people who indicate their willingness to pair with me. Of course, a beginner could erroneously call themselves an "ambassador" but we should probably have some sort of overarching policy of graciousness in which pairs don't take these labels too seriously and are ALL eager to both teach and learn.

That's actually a great idea. We don't want to scare people away but rather promote a diverse community including all levels of experience.

Agreed. This could get more interesting/complicated if we have it be about projects and/or languages. I think we should discuss this more.

Perhaps to start, we allow users to add languages, frameworks and libraries to their profile with a associated label such as "Novice", "Intermediate", "Advanced" and "Expert". The labels could of course be reworded in a more playful manner. This would also address the question above.

Thrillberg commented 5 years ago

Here is an incredibly rough sketch. I'm not tied to anything in here at all, but I thought it might be nice to mock up a possibility to get more questions out. I think it's mostly self-explanatory except for the pawn icons I have under the languages. Those indicate the comfort level of the user with pairing with someone who is inexperienced in a given language. So in this example, the person wants to pair in either Ruby or JS (or both) and is comfortable with a novice in Ruby but not JS. I think as a default we might want all languages checked and force the user to uncheck those they don't want to pair on. And leave all pawns at full opacity to force the user to reject inexperienced pairs by clicking the pawn by the language and thereby adding opacity.

Hopefully that wasn't too convoluted! Oh yeah, and I figure the calendar looking thing can be filled in with pairing appointments and the time entry at the bottom is dropdown items to select from.

Again, I don't want us to feel bound to this idea or anything else at this point, but I thought it couldn't hurt to get something out there to move discussion forward.

codetogether