On 05/29/2015 01:48 PM, Stefano Maffulli wrote:
Slides & content ================
- I think the rst format and common repository worked well. We miss one (set of) slides to illustrate the whole 2 days program. Maybe copying the content over from the wiki Info page[1] to the index.rst page would be a good thing.
- the index.rst is not formatted properly. Christian Berendt is working on this and may need a help from sphinx/hieroglyph gurus https://review.openstack.org/#/c/185946/
- the draft site[2] is great. I think that keeping the slides in /draft/ is good enough since the status of those slides may not be always up to date with the authoritative source of information like governance.o.o or infra/manual
- with the slides in .rst format and in a git repo, I think they could be hooked to a translation system. I'd consider hooking up and translate the material in other languages. Japanese would be the most likely candidate, and people from China have expressed also interest.
- suggestions and commentts from the participants:
+ Maybe work through some more demos - ie, run through committing a change to sandbox doing it "live" from the presenter desk
The sandbox was a great addition! I remember feeling a wave of panic when I submitted my first WIP review request to a real project, and the sandbox project would have helped me get comfortable with the process.
+ Point out the differences between docs and code reviews - environment prerequisites + Talk about gating checks - ie, what the automated checks are actually checking for. + It might be worth considering recording it and making it like a Coursera course or a Kahn Academy course.
I heard this from a few students as well: even though they just saw all of the material, they thought videos for review would be helpful once they returned home. I'll be offering the course to some colleagues via Google+ Hangouts in the next few weeks. I can record those sessions, then we can evaluate the usefulness, edit them, or re-record as necessary.
+ The slideshow can improved. It should contain more graphics (ex: apc/atc relation), clickable links (ex: stackforge). + It would be great to collect a list of bugs which are really "low hanging" fruits, so that they can be solved during the two days. + Teach about the source code. How it's organized? Why is it so? After rpm/deb packaging, where do files go on the root filesystem? How do I run tests? How do I write my own tests? What if I need to introduce a new file? How are the python packages arranged? How do subprograms communicate to each other? + consider separating software developers and technical writers
One more comment led me to believe that we have not done a good job at communicating that the training is 2 days live + mentoring sessions afterwards. See below for ideas on how to fix this.
Administrative process ======================
- Planning attendance is hard. Of the 85+ people who originally signed up, about 45 showed up. I noticed that about 10 people removed themselves when we started sending notifications in preparation to the live session. I think that the barrier to sign up is too low and we can raise it so that only highly motivated people sign up to attend. The low barrier also makes it hard for people to read and understand that the training is 2 days live + online mentoring afterwards.
What if we had an interactive onboarding page that walked people through all of the administrative steps required to contribute? 1. Sign up for Upstream Training 2. Receive instructions to complete the onboarding process 3. If 7 days pass and onboarding is incomplete, drop the registration. A quick mock up: http://tim.freunds.net/media/images/upstream-prep-page-mockup.png That would provide a filter, ensure that all participants are ready to contribute once they understand the process, and allow us to shrink a traditionally troublesome part of the training.
+ To set the bar higher, I think we need to find a way to scale the method used by Loic. He engages with every applicant immediately, as they sign up, and if they don't respond to his solicitations he removes them from the list. That's very intense and time consuming but ends up getting more motivated people. I think this can be scaled by having a larger pool of mentors that gets to solicit applicants. A form of light automation using Google Forms and Trello (with glue provided by zapier.com) may be enough? Needs experimenting.
+ To make it clear that the training is 2 days + live sessions I think we should have people engage with mentors and set dates for meetings *before* the training starts.
Capturing the enthusiasm early in the process to get the first post-class mentoring meeting set up will be very helpful. I think it's the most powerful part of the training, but it's easy to ignore if dates aren't set before students return home.
- I think the Trello board is a good step forward: it allows staff and management to follow progress of each student.
Format ======
- I'm starting to think that to days is probably too much for some people. The comments I have received from the survey are all extremely positive but a couple of written comments make me believe that trying to shorten the class to 1 day and 1 extra day for custom deep dives would probably give more value. This deserves a thread on its own.
Venue & logistics =================
- Participants and staff should have their names printed to facilitate social interactions
+1. I wrote everyone's names on a sheet of paper next to my laptop, but that didn't help once we were moving around and building. :-)
- Renting the Legos was the best idea ever. Definitely worth considering for the future.
Thanks again, stef
[1] https://wiki.openstack.org/wiki/OpenStack_Upstream_Training/Info [2] http://docs.openstack.org/draft/upstream-training/#1
Thanks, Tim -- Tim Freund 913-207-0983 | @timfreund http://tim.freunds.net