From Teaching Open Source
This page is for planning notes, meeting information, etc. around the 0.8.1 release of Practical OSS Exploration.
Contents |
[edit] Design process
(yay!)
-
Needfinding - listen and watch in actual classes we can always do more -
Brainstorming attributes of our user group (and grouping them) -
Persona creation (we have these, need to publish) -
Brainstorming potential solutions and narrowing down and sketching them(we know one of these narrowed-down solutions is the textbook, another is the curriculum, but may come out with other supporting material ideas others can pick up on from this process) - Defining learning objectives, group by chapter
- Design evaluation methods for each of these learning objectives (by chapter)
- Write the chapter
- Get first-round feedback; test against personas, ask for reviewers
[edit] To do
Things that need to be done (let's list them out first and then lay them into milestones/dates)
- Scope missing chapters
- Find content or write for missing chapters
- Identify and balance learning objectives
- Some are already grouped in the chapters, make sure they are in the right locations and complete
- enter learning objectives for each chapter (quiz questions at the end, like 4th grade history texbooks?) If that's the way we want to evaluate it, yes.
- Self-evaluation against a defined learning objective (lo).
- Improve lo iteratively over time based on student and professor feedback.
- Evaluation methods for each learning objective (by chapter)
- Resolve contributor attribution details.
- Start stand-alone forum on tos.org for wide open discussions
- Start OSU-specific forum on beaversource
- Rewrite chapters to make voice match
- Final revisions/copyediting
- Generation of PDF version
- Curriculum tested/deployed with textbook as central resource ("final release")
- Collect feedback
I wonder if making the "release cycle" be semester-based (NA schedule) would work for this round. (suggest also a quarter-oriented cycle for those schools using 10-week quarters)
[edit] Learning objectives
http://web.mit.edu/tll/teaching-materials/learning-objectives/index-learning-objectives.html
- Persistently and politely ask a well-targeted question for help working on a FOSS project in the IRC channel an experienced contributor to that project would hang out in until an answer is received. (Inferred: Know how to find the IRC channel and the person you should ask.)
- Document a walkthrough of the help received in that IRC channel on the project's wiki page. (Inferred: find the wiki and know how to use it)
- Post the URL of the walkthrough they just wrote to the project's mailing list in a call-to-action way that generates further feedback and response. (Inferred: find the mailing list and know how to use it.)
- Blog a reflection on the experience - the help you got, where you wrote it up, what you were able to do with the new things you've learned - and have it find its way to your class planet, the project's planet, or both. (Inferred: Have a blog and know how to get it on a planet.)
- Organize or attend an in-person or remote hackathon for the project you are working on
[edit] Learning objectives by chapters
[edit] Needs assessment
- What textbooks in use.
- How they are used.
- How are books chosen?
- How do you use a textbook?
- What is the itch so we can scratch it?
[edit] Assumptions
- Written in certain format.
- Consistent.
- Chosen by professor, not student.
- ???
[edit] Personas and Values
These are constructed personas to represent different types of instructors who might use this textbook.
[edit] Anna
- Industry background.
- CS PhD worked for Google pre-IPO and through IPO.
- 20% time worked teaching CS in East Palo Alto High Schools.
- Decided after 7 years to return to teach.
- CS PhD worked for Google pre-IPO and through IPO.
- Young, starting career as professor.
- Liberal arts school.
- Students have affluent backgrounds.
- CS professor.
- First faculty interested in open source but has permission.
- First one in a supportive environment.
- Bridging personality type, meta-teacher.
- Brave.
- Willing to try new ideas, even experiments, even at risk to self, but never to students.
[edit] Anna values
- Rich, thorough research.
- Undergraduate research.
- Innovation and new thinking.
- Cares about diversity issues especially in CS.
- Used to looking good, not as experienced with public failure.
- 35, engaged, no children.
[edit] Richard
- Existing FOSS contributor.
- PhD from Java research, lightweight contributor during grad school.
- Attempted Java-based startup from PhD research early in professorial career but burned by experience.
- Worked on parts of GNU Classpath and toward OpenJDK, soured by Sun's control of Java.
- Foot in both worlds of ACAD and FOSS, but hasn't gotten the two together quite yet.
- Newly tenured.
- No-industry experience.
- More bold with tenure.
- Teaching school with 2 year and 4 year degrees.
- Mandate to get students industry connections as part of education.
- Large classes, varied socioeconomic backgrounds.
- Students work, may be first going to college.
- Non-supportive colleagues.
[edit] Values
Not written
[edit] Carl
- Research institution.
- CS colleagues already teaching open source.
- No bridge yet across the "it's a code thing" side.
- Journalism professor.
- Teaches intro to tech writing, first year humanities class, and senior-level mass communication seminar.
- Has 4 grad students.
- Research area, "African-American Computer Scientists as Covered By Mass Media"
- Coming up for tenure.
- No FOSS contribution skills.
- Exposed to the open source way by a nagging grad student.
[edit] Values
Not written
[edit] Problem framing
Why is not having a textbook a problem?
- Student's expect a textbook and there isn't one.
- I don't have enough time to create assignments from scratch.
- It's easy to get lost in FOSS, professors and students; textbook as guide/map.
[edit] Ideation
...
[edit] Gallery sketches
- Take ideation posters and cull down to a few things to prototype.
[edit] Learning objectives
- Goals from industry designing for.
- Bloom's taxonomy. ISBN 0-582-28010-9
That gives us the learning objective, which is our test of success/failure of the textbook.
[edit] Draft outlines and chapters
- Earlier work gives skeleton.
- Scope work based on skeleton.
[edit] Assessment
- Draft or plans are in place.
- Go back through previous stages quickly to make sure things match up with interviews, personas, etc.
[edit] Implementation
- Finished product.
- Academic source.
- Now, how do you get it used?
[edit] Future notes
These notes were originally taken for the 0.9 release but could be used in 0.8.1.
Some issues that we should consider for the 0.9 Release:
- Some chapters begin with a very standard "what you should learn in this chapter" section. Other chapters lack this. We really should strive to make that consistent across all chapters.
- There are a number of terms about which we assume previous knowledge. One simple option is to hyperlink to good explanations of these terms externally; but a better solution might be to link to a glossary at the end of the text. We're starting to collect these in our Glossary of Terms.
- We should explain who this book is for (for instance, in a section in the introduction titled "who this book is for"). This will be a (nonexclusive) description of our target audience that helps people understand the assumptions we may be making as we write. One suggestion was to create personas for the book. FIX in Foreward
- Make a student-like session working on code, e.g. "Here is an example of a social moment on IRC:" and "Here is an example of working on code in IRC:" FIX in The Lay of the Land
[edit] Who is using the textbook
[edit] Fall 2010
Confirmed:
- Heidi Ellis (Western New England College)
- Gregory Hislop (Drexel University)
- Karl Wurst (Worcester State University)
To ask:
[edit] Spring 2011
- Tim Budd (Oregon State University)