[openstack-community] [upstream] Vancouver upstream training session debrief
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 + 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? + 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. + 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. - 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 - 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
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
On 05/30/2015 09:15 AM, Tim Freund wrote:
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.
Sounds good, although video requires a huge investment not only in production but also in later maintenance. Things get updated (too) quickly and video content becomes stale too soon. It's worth giving it a shot though.
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 looks great indeed. Something like that would be also useful for a concept I and Thierry have been tossing around for a while: a 'ladder' with small individual steps to climb on until the top. And the top would be different for different roles. One first very rudimentary attempt of such ladder for ATCs is the wiki page https://wiki.openstack.org/wiki/From_zero_to_ATC although it currently is just a list of links organized in a sort of chronological order.
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.
I think it's a great idea: provide a way to confirm their intentions by going through a series of small tasks to get them ready for the training in person. /stef
-----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-----
On 05/29/2015 07:48 PM, Stefano Maffulli wrote:
+ 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?
I had the impression that most of the people had already in mind to which project they wanted to contribute. Maybe we can provide deep dive sessions of a couple of hours on some project (nova, neutron, etc) so that it's going to be easier for them to start contributing. cheers, Rossella
Are we going to discuss about CI using git and jenkins, or any kind of tools? I think that each repository is already there. - Kinjo On Thu, Jun 4, 2015 at 1:05 AM, Rossella Sblendido <rsblendido@suse.com> wrote:
On 05/29/2015 07:48 PM, Stefano Maffulli wrote:
+ 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?
I had the impression that most of the people had already in mind to which project they wanted to contribute. Maybe we can provide deep dive sessions of a couple of hours on some project (nova, neutron, etc) so that it's going to be easier for them to start contributing.
cheers,
Rossella
_______________________________________________ Community mailing list Community@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/community
-- Life w/ Linux <http://i-shinobu.hatenablog.com/>
participants (5)
-
Lana Brindley
-
Rossella Sblendido
-
Shinobu Kinjo
-
Stefano Maffulli
-
Tim Freund