librelist archives

« back to archive

The Onboarding Process

The Onboarding Process

From:
Katrina Owen
Date:
2013-08-21 @ 05:31
Hi,

I've got a lot of half-baked, vague, and fuzzy thoughts, and I can't
seem to get any of them straight. Therefore, you're going to get them
all crooked-like.

Right now people are very, very confused when getting to the site: What 
does it do? What is it about? What are they going to get out of it?

Then they (somehow) decide to try it out. Now they're confused about how 
to get started. And when they finally figure *that* out and submit 
something, then they're confused about the next steps. Who is going to 
give feedback? When? How will they know? What are they supposed to do 
while waiting?

This confusion is then exacerbated by the fact that there's no guidance
in helping people provide good feedback. I have some pretty clear ideas 
about what good nitpicking looks like, and I haven't communicated that 
anywhere. A lot of rounds of feedback go really wonky, where the 
nitpickers are either cargo-culting feedback that they received (and which
doesn't apply) or pushing the code in really crazy directions, or just 
focusing on tiny stuff while ignoring the bigger picture things. Some 
people end up in an endless loop of bikeshedding. Even though I use the 
term bikeshedding on the site, I actually don't want it to feel like 
bikeshedding.

I wrote up a first draft of a "guide to a typical Bob" about nitpicking.
For now it's here: http://exercism.io/nitpick/ruby/bob

I don't know how much of this is appropriate to communicate, or to
whom, or when.

So there's this whole style of communication that I want to explore and/or
help people acquire.

So somehow people have gotten to the site, decided that they'll try it
out, figured out how to submit code, gotten feedback, and eventually their
next assignment gets unlocked.

How are they supposed to know to go to nitpick things? There should be 
some way of indicating/encouraging people to nitpick, much less how to 
help people get better at nitpicking.

I want this to be a safe place to experiment and play, a place where it
is safe to learn, to try, to write awkward code. I want to help people
learn how to give and get feedback (and learn it myself).

Katrina

Re: [exercism] The Onboarding Process

From:
Zach Briggs
Date:
2013-08-21 @ 13:09
Great thoughts!

How would we approach this if it were a presentation? What do we need to
convey, and where are our opportunities to convey it?


On Wed, Aug 21, 2013 at 1:31 AM, Katrina Owen <_@kytrinyx.com> wrote:

> Hi,
>
> I've got a lot of half-baked, vague, and fuzzy thoughts, and I can't
> seem to get any of them straight. Therefore, you're going to get them
> all crooked-like.
>
> Right now people are very, very confused when getting to the site: What
> does it do? What is it about? What are they going to get out of it?
>
> Then they (somehow) decide to try it out. Now they're confused about how
> to get started. And when they finally figure *that* out and submit
> something, then they're confused about the next steps. Who is going to give
> feedback? When? How will they know? What are they supposed to do while
> waiting?
>
> This confusion is then exacerbated by the fact that there's no guidance
> in helping people provide good feedback. I have some pretty clear ideas
> about what good nitpicking looks like, and I haven't communicated that
> anywhere. A lot of rounds of feedback go really wonky, where the nitpickers
> are either cargo-culting feedback that they received (and which doesn't
> apply) or pushing the code in really crazy directions, or just focusing on
> tiny stuff while ignoring the bigger picture things. Some people end up in
> an endless loop of bikeshedding. Even though I use the term bikeshedding on
> the site, I actually don't want it to feel like bikeshedding.
>
> I wrote up a first draft of a "guide to a typical Bob" about nitpicking.
> For now it's here: http://exercism.io/nitpick/ruby/bob
>
> I don't know how much of this is appropriate to communicate, or to
> whom, or when.
>
> So there's this whole style of communication that I want to explore and/or
> help people acquire.
>
> So somehow people have gotten to the site, decided that they'll try it
> out, figured out how to submit code, gotten feedback, and eventually their
> next assignment gets unlocked.
>
> How are they supposed to know to go to nitpick things? There should be
> some way of indicating/encouraging people to nitpick, much less how to help
> people get better at nitpicking.
>
> I want this to be a safe place to experiment and play, a place where it
> is safe to learn, to try, to write awkward code. I want to help people
> learn how to give and get feedback (and learn it myself).
>
> Katrina
>
>

Re: [exercism] The Onboarding Process

From:
Katrina Owen
Date:
2013-08-29 @ 03:53
On 08/22, Joseph Caudle wrote:
> > How are they supposed to know to go to nitpick things?
> > There should be some way of indicating/encouraging
> > people to nitpick, much less how to help people get
> > better at nitpicking.

> I'm curious if we know what the answers are to some of these questions?
> I think hashing them out on a wiki or something might not be a bad idea.

A wiki could work. The one on exercism.io is editable by anyone.

> I know there's a huge cognitive investment when starting a lot of blogs,
> but would it make sense to put this on a simple tumblr site that
> redirects to blog.exercism.io?

I definitely want a blog, but I don't know how to begin. I don't know
what to say, I feel like a blog is step 3 or 4 in this process. There
needs to be something else first. I think.

> > So there's this whole style of communication that I want to
> > explore and/or help people acquire.

> I think this above all else could be a great thing to put front
> and center on the site.
> "Learn how to communicate your technical thoughts."

Maybe, but I feel like that's not something I can teach, because I don't
know how to do it myself. I just have some ideas about what works better
than others... when I see it.

> > I want this to be a safe place to experiment and play, a place where
> > it is safe to learn, to try, to write awkward code. I want to help people
> > learn how to give and get feedback (and learn it myself).

> This honestly sounds like it could make another great one-off posts.
> Either that or more information for the front page.

I think the front page might have too much / the wrong information.
I'm not sure what the most important idea(s) is (are).

Katrina

Re: [exercism] The Onboarding Process

From:
Joseph Caudle
Date:
2013-09-23 @ 05:53
Sorry to have taken so long to respond. I've been detained with personal 
matters. Please forgive my absence.

> On Aug 28, 2013, at 23:53, Katrina Owen <_@kytrinyx.com> wrote:
> 
> On 08/22, Joseph Caudle wrote:
>>> How are they supposed to know to go to nitpick things?
>>> There should be some way of indicating/encouraging
>>> people to nitpick, much less how to help people get
>>> better at nitpicking.
> 
>> I'm curious if we know what the answers are to some of these questions?
>> I think hashing them out on a wiki or something might not be a bad idea.
> 
> A wiki could work. The one on exercism.io is editable by anyone.

It doesn't look like there's anything there yet. If you brain dump some 
pages you'd like to see, I'll put some meat on the skeleton you sketch. 

>> I know there's a huge cognitive investment when starting a lot of blogs,
>> but would it make sense to put this on a simple tumblr site that
>> redirects to blog.exercism.io?
> 
> I definitely want a blog, but I don't know how to begin. I don't know
> what to say, I feel like a blog is step 3 or 4 in this process. There
> needs to be something else first. I think.

Agreed. Let's see how the wiki works out. We might outgrow GitHub's wiki 
or want an "authoritative" source at some point, but let's get a good 
foundation built. 

>>> So there's this whole style of communication that I want to
>>> explore and/or help people acquire.
> 
>> I think this above all else could be a great thing to put front
>> and center on the site.
>> "Learn how to communicate your technical thoughts."
> 
> Maybe, but I feel like that's not something I can teach, because I don't
> know how to do it myself. I just have some ideas about what works better
> than others... when I see it.

Teaching by learning in public is one of the best forms of education. I 
think this idea could easily go on the front page. It's not like we're 
offering anyone a real teacher other than themselves and the nitpicking 
community.

>>> I want this to be a safe place to experiment and play, a place where
>>> it is safe to learn, to try, to write awkward code. I want to help people
>>> learn how to give and get feedback (and learn it myself).
> 
>> This honestly sounds like it could make another great one-off posts.
>> Either that or more information for the front page.
> 
> I think the front page might have too much / the wrong information.
> I'm not sure what the most important idea(s) is (are).

Again, this sounds like something we can figure out once we have some 
drafts to work out. Feel free to brain dump here or on the wiki. 

Best,
Joseph

Re: [exercism] The Onboarding Process

From:
Katrina Owen
Date:
2013-08-29 @ 03:46
On 08/21, Zach Briggs wrote:
> How would we approach this if it were a presentation? What do we need to
> convey, and where are our opportunities to convey it?

A week later, and I still don't have any idea where to begin with this.

Re: [exercism] The Onboarding Process

From:
Joseph Caudle
Date:
2013-08-22 @ 03:40
On Aug 21, 2013, at 1:31 AM, Katrina Owen <_@kytrinyx.com> wrote:

> I've got a lot of half-baked, vague, and fuzzy thoughts, and I can't
> seem to get any of them straight. Therefore, you're going to get them
> all crooked-like.

Thanks for sharing them!

> Right now people are very, very confused when getting to the site: What 
does it do? What is it about? What are they going to get out of it?
> 
> Then they (somehow) decide to try it out. Now they're confused about how
to get started. And when they finally figure *that* out and submit 
something, then they're confused about the next steps. Who is going to 
give feedback? When? How will they know? What are they supposed to do 
while waiting?
> 
> This confusion is then exacerbated by the fact that there's no guidance
> in helping people provide good feedback. I have some pretty clear ideas 
about what good nitpicking looks like, and I haven't communicated that 
anywhere. A lot of rounds of feedback go really wonky, where the 
nitpickers are either cargo-culting feedback that they received (and which
doesn't apply) or pushing the code in really crazy directions, or just 
focusing on tiny stuff while ignoring the bigger picture things. Some 
people end up in an endless loop of bikeshedding. Even though I use the 
term bikeshedding on the site, I actually don't want it to feel like bike 
shedding.

> So somehow people have gotten to the site, decided that they'll try it
> out, figured out how to submit code, gotten feedback, and eventually 
their next assignment gets unlocked.
> 
> How are they supposed to know to go to nitpick things? There should be 
some way of indicating/encouraging people to nitpick, much less how to 
help people get better at nitpicking.

I'm curious if we know what the answers are to some of these questions? I 
think hashing them out on a wiki or something might not be a bad idea. I 
think the wiki on github.com/kytrinyx/exercism.io might be a perfect 
place, or a separate thread to talk about some of these questions here 
could also work.

> I wrote up a first draft of a "guide to a typical Bob" about nitpicking.
> For now it's here: http://exercism.io/nitpick/ruby/bob

The draft looks great. I know there's a huge cognitive investment when 
starting a lot of blogs, but would it make sense to put this on a simple 
tumblr site that redirects to blog.exercism.io? Just something to get 
going and provide a place for maintainers to say what they'd like easily 
about the site? Other options than Tumblr could work of course, it's just 
really low hassle.

> So there's this whole style of communication that I want to explore 
and/or help people acquire.

I think this above all else could be a great thing to put front and center
on the site. "Learn how to communicate your technical thoughts."

> I want this to be a safe place to experiment and play, a place where it
> is safe to learn, to try, to write awkward code. I want to help people
> learn how to give and get feedback (and learn it myself).

This honestly sounds like it could make another great one-off posts. 
Either that or more information for the front page.

A lot of this is really helpful for figuring out the messaging. Perhaps we
could schedule an IRC hangout to discuss more of this in real time, or 
maybe just keep hashing it out in separate threads. I like where it's 
going though.

Joseph