-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30/05/15 03:48, Stefano Maffulli wrote:
Hello folks,
first of all thank you to all instructors and volunteer staff and mentors that helped in Vancouver: this program would not be possible without the kind donations of your time and effort.
I'd like to collect notes and comments on what went well and what should be changed for the next events. I'll start (quite long):
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 + Point out the differences between docs and code reviews - environment prerequisites
I think perhaps a few more "do it [x] way in dev, for docs do [y]" would be useful.
+ 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. + 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?
+1
+ consider separating software developers and technical writers
I'm strongly against this. We need to keep reminding people that docs work in the same was as dev projects, with a few quite minor differences.
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.
+ 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.
+1
- 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.
It's a lot of content, is it too much to expect people to absorb all that in half the time? From what I saw of questions on the second afternoon, they need that thinking time to sort out the brain dump of info they had on day 1. I saw a lot of 'lightbulb' moments on Sunday that I worry wouldn't happen if it was a one day course.
Venue & logistics =================
- Participants and staff should have their names printed to facilitate social interactions - Renting the Legos was the best idea ever. Definitely worth considering for the future.
Thanks again, stef
Stef, just wanted to add that as my first time at this training I had a great experience. It was truly satisfying to see people go from zero to ATC, and I certainly picked up a few newbies who then made it to my sessions during the Summit, and hit ATC a few days later as well. Very well organised and run :) Lana - -- Lana Brindley Technical Writer Rackspace Cloud Builders Australia http://lanabrindley.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVa5FTAAoJELppzVb4+KUyJi4H/0qBZ7ZH7EckDwu24Lp1JzrW DQ/5nvejDs3vwGGNBZCSKFKydtb1uLnRb/VUMjuTmbHvMi69gE51ylUKEbfzMabR PN8Ekfoy3Xmt4U6AJrRis6d8n+e3ZbQPJK+8LqUNnCr2iHPIBQQSqzJGtlcCmHiN XtPm67vb3pH7dZhbgCvy47PK+LwZHf1JcEhpdkwRlVqMnw3Iqimi+ax9nDTy6He4 vW5gDYit63FVdqbXLTGjCWUw4+oaL/fjmy8Hg2Mk8qfAVex66IC9hj4PsV9Gv26B LUrabsd9U1NodkDKVHYHpdE6n21rFz1SwZCzAIy1xB5Ph8MRqj4iRvfukDChn10= =1akI -----END PGP SIGNATURE-----