Community Data Science Workshops (Fall 2014)/Reflections: Difference between revisions

imported>Mako
imported>Mako
Line 196:
== General Feedback ==
 
* Generally, there was a sense that we should stop creating pages in the wikwiki by copying and pasting old stuff. This was the BPW model but it's leading to madness. We when archive thean old version of a site, we can use MediaWiki to create links to the old version of the pages (we can intstall templates from English Wikipedia) to help make this easier).
* We should try to schedule the workshop not asquite so close to the end of the quarter. The beginning or middle of the quarter should be better for UW students.
* Mentors should post the code generated in the break-outsout sessions. Encourage them to capture the code created in examples and to post these afterward systematically.
* There was general interest in pair programming or more team based excercises. We should consider changes along this line.
 
* There was a need for several on-the-fly corrections of the instructions and files on the wiki during the workshop. Better planning and testing for this will be very useful.
 
=== Mentorship ===
 
Last time through, most of our observation were focused on improving the experience of attendees and we think we didn't spend as much time on helping mentors have a great experience and helping them prepare effectively. We had many new mentors this round. One general concern was the relative lack of mentor training, especially before the first sessions. We had a series of pieces of feedback on how to improve this.
 
We had many new mentors this round. One general concern was the relative lack of mentor training, especially before the first sessions. We felt that we should:
 
 
* Arrange a pre-CDSW mentors meeting (perhaps a day or two before to over material) and maybe at a bar or other social environment with beer and pizza. We coudlcould use this tnormsto set norms, best practices, goals, planning, etc.
* Perhaps meet 15-20 minutes early before Session 0 to get to know each other and over things.
* Create some easier way to distinguish mentors from students (e.g., t-shirts, buttons, paper them head to foot in sticky notes).
* Send out detailsdetailed instructions and emails to mentors, or create pages in this wiki, withthat detail ongood howmentoring. toFor do this better.example:
** Talk to mentors aboutHow much should you help? (eSome.g., some butBut be careful not to just give away the answer, to focus too much on elegance or technical correctness. and beBe careful not to overwhelm the learners).
** Explicitly encourage mentors to reach out to students and ask them how things are going by walking around to every single person to ask, “How are you doing? What are you working on? Show me what you’re doing.”
 
=== More Projects or Better Projects ===
 
WeOnce again, we had certain afternoon project sessions that were much more effective than others. One thing we were conflited about was whether we wanted more break-out sessions or whether we should just use the best of the break-out sessions (perhaps in two rooms).
 
Arguments for smaller groups of the best break-out session include:
Line 230 ⟶ 226:
* Diversity of projects inspires people to do the kinds of things that people can do with this new knowledge. 

 
OtjherWe should pursue other ways to encourage generative-ness?creativity mightwith includecode. For example, we might givinggive participants creative/flexible moments within sessions and lectures might be empowering in simlar ways. Perhaps,We can also continue to callingcall out participants who are doing creative things?.
 
== Budget ==
Anonymous user