[Ccsf-campus-staff] how did the event go?
Shauna Gordon-McKeon
shaunagm at gmail.com
Wed May 21 19:09:20 UTC 2014
(Note: I'm going to be trying to do a bunch of curriculum improvements over
the summer. If you're interested in helping with that, you should join
http://lists.openhatch.org/mailman/listinfo/osctc-planning.)
Lots of lovely feedback to respond to! Here goes. I'm going to add some
"$So-and-so said"s to hopefully keep this readable.
*Veronica Ray wrote:*
*"I wasn't happy with my part of the contribution workshop. No one had used
Rails before or had their computers set up for Rails development. Next time
I would announce my part of the workshop and make sure interested students
were set up to develop in Rails before Saturday. (Alternatively, I would
have picked a language/framework that people in the workshop were familiar
with.)"*
I'm sorry to hear that development environment setup is an issue. Based in
part on your feedback, we've changed our process for pre-event setup a bit.
We now ask mentors for projects that will be worked on to provide a brief
blurb (covering what their project is/how to set it up/how to contact them
for help) and send it out to students a week or so before the event. Only
a small number of students actually go through this process, but I think it
does help a little bit. Veronica, if you have additional suggestions to
fix this issue, I'm all ears!
*"I ended up working intensively with a couple people to set up their
environments and walk through how I solved the issue. That was very
rewarding."*
Am I understanding correctly that you walked through the process of how you
solved an already-solved issue? That sounds like a brilliant idea and
something we should make part of our curriculum!
*Katherine Moloney <kmoloney at mail.ccsf.edu <kmoloney at mail.ccsf.edu>> wrote:*
+ Suggestions:
> => A Code of Conduct – one mentor reported inappropriate behavior
> from an attendee (“you have such pretty eyes” and unnecessarily touching
> his arm) – mentor said this didn’t bother him, but wanted us to know about
> it since it was unprofessional. I don’t raise the point that ‘this didn’t
> bother X’ to de-emphasize the issue, only to give context. Definitely will
> be implementing an explicit code of conduct in the future
>
I'm sorry to hear that issue arose! This is the first report of
inappropriate behavior we've had at one of our events (which may mean there
hasn't been inappropriate behavior, or it may mean we've done a poor job of
helping people report it). We've included a link to our Code of Conduct in
the template we use for publicity websites. We could potentially include a
link in emails and/or explicitly mention it at the start of the day,
although so far we haven't done that.
> => Make sure food is conducive to a long day – less sugar snacks,
> more fats & proteins (“long burning fuels” for the body)
>
I have added this piece of advice to our documentation on the wiki, thanks!
> => Next time have separate buttons on the event page for “Attendee”
> and “Mentor” registration
>
Our template publicity website now includes this. :)
> ++ Next time, add to git/GitHub curriculum:
> ==>> Begin with a simple **diagram** to reinforce
> concepts of:
> +++ Git on my local machine – writeable/pushable
> +++ GitHub – my account – writeable/clonable
> +++ GitHub – someone else’s account –
> readable/forkable
>
Please let us know what you add! I am also going to be brainstorming how
to improve the curriculum over the summer (I'll be documenting that on the
osctc-planning mailing list), and may make some changes here myself.
>
> ++ Separate irc off as its own separate session (at least for
> future CCSF sessions)
> ==>> Do this first, so more advanced students can chat
> with each other while beginners practice
> ==>> With all students, share some reference links via
> irc channel:
> +++ Command line:
> https://openhatch.org/wiki/Open_Source_Comes_to_Campus/Curriculum/Laptop_setup#Goal_.232:_practice_navigating_from_the_command_line
> +++ irc commands:
> http://www.ircbeginner.com/ircinfo/ircc-commands.html
> +++ all other step-by-step curricula as they get
> started
>
Again, hoping to improve this part of the curriculum this summer. I've
been trying to brainstorm a good activity to help people get comfortable.
I like your idea of putting it at the beginning of the day.
> ++ how to log irc channels so you can read the activity that
> happened when you’ve been away
>
This would be a great addition to the curriculum. If you want help
creating it, just let me (and osctc-planning) know.
>
>
> + Organization
> => Next time print out a sign in sheet, so we know which of the
> registrants actually come (this time we just got the head count & the
> gender breakdown, but not a complete list of who came [though if I sat down
> & marked off all that I personally recognize I could probably ID 60% of the
> attendees, maybe more])
> ++ Useful to see % attendance rate for varying populations
> (directly from clubs, from the CS dept, from other depts, from other
> programs)
>
We've got a template sign-in sheet in the repository now. Yay!
> => Like Railsbridge curricula (docs.railsbridge.org), would be nice
> to have the lesson written out, so students can follow
>
Do you mean the details of each activity, or the overall schedule of the
day? It's a good point either way - some people really benefit from having
everything written out for them ahead of time.
> ++ When we work working on the git/GitHub session, when trying to
> help catch up lagging attendees, when we would look up, we would have no
> idea where the group was in the project directory structure (as Veronica
> brought up, the MVC directory structure was too complex for those without
> any experience with Rails to “catch up” [i.e. find the next file which was
> being modified])
>
I'm a little confused by this - MVC directory structure in Git/Github
session? I can't comment on that, since I think I'm missing something,
but generally for helping lagging attendees we've adopted the Software
Carpentry sticky note method, which I highly recommend. You can read about
it here: http://software-carpentry.org/bootcamps/operations.html#sign_in
=> Interestingly, many attendees had already read thru the entire
> OpenHatch curricula, and were hoping that the workshop would go beyond the
> written classroom
>
Yeah... not sure what to do about this. It seems beneficial to make the
materials open ahead of time so folks can get started, but then this sort
of thing happens. Perhaps by improving the curriculum and adding to it,
we'll create more modules than people can reasonably go through ahead of
time. (We're also going to try and create more beginner/moderate/advanced
structure, whether that's different activities or just pairing certain
students with more experienced mentors on a given task.)
> => Would be nice to have attendees self-select into different groups,
> as at the Bridgetroll workshop (and many others I’m sure)
>
How do you mean?
> => Liked the small group discussion period in the middle of Maria’s
> communication tools presentation
>
Can you tell me more about this?
> => Possibility: monthly Open Source (possibly OpenHatch) meetup,
> possibly thru Noisebridge or Women Who Code
> ++ This would support:
> ==>> A place for students to continue going to carry on
> ==>> A place to build community, which would help
> increase the number of mentors recruited for future workshops
>
This sounds great. OpenHatch has done a couple of in person sprints/events
as well, which we should make sure students and mentors are invited to.
We've also talked about doing some regular IRC-based meetups, which local
groups could attend, if they wanted to, by all meeting up at a cafe or room
on campus.
We're happy to collaborate with other groups as well.
>
> => Next Time…
> ++ Have registrants self-select into groups based on experience
> when they register (similar to Bridgetroll --
> http://www.bridgetroll.org/events/87/levels -- though as a starter
> probably will be 3 groups [totally new to programming, beginner/student
> level programmer, competent programmer])
>
Our sign up survey asks these questions, but we don't typically do much
with it. I agree that self-selection into experience levels would improve
things.
> ==>> Consider having students work at their own pace
> within each curriculum module, and ask help from mentors as needed, mentors
> call attention of group for answer that they think will be broadly
> applicable
> +++ Even if curriculum remains mentor-lead, at least
> students can catch back up with the group
>
Hmmm. I like this idea. There's trade-offs between self-guided materials
and other kinds of activities, and I've been favoring self-guided materials
for other reasons (it makes life a lot easier for events where there aren't
enough mentors) so I'm glad to see there are other benefits too.
> ==>> Build out the curriculum, so there is baseline to
> accomplish & then deeper and deeper levels that more experienced students
> can work on
>
Yes! Join osctc-planning. :)
*Maria Pacana wrote:*
*<a description of her activity>*
So I created this activity for events to use:
https://openhatch.org/wiki/Open_Source_Comes_to_Campus/Curriculum/Finding_a_Project
It seems to have been mildly successful at a couple of events. I'd love it
if you could give it a look over and see where it differs from your
activity and how it could be improved. Your activity seems to focus a bit
more on contacting the project, which I think is right-on -- contacting the
project can be a significant mental hurdle and I'd be happy to add more to
the activity to make folks more comfortable with it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhatch.org/pipermail/ccsf-campus-staff/attachments/20140521/00d37e5e/attachment-0001.html>
More information about the ccsf-campus-staff
mailing list