OSCON 2010

From Teaching Open Source

Jump to: navigation, search

This page is rough and incomplete - it is turning into a page for planning our presence at OSCON 2010. If you hit this page and have questions (since the page is still rough), please drop the mailing list a line and we'll come in and fix it (you'll be doing us a favor by asking questions!)

Original content based on this mailing list thread.

Contents

[edit] BoF proposal

Mel Chua has submitted a BoF proposal for Monday night. Abstract is as follows.

This BoF, run by members of the http://teachingopensource.org community and open to all, hosts discussion on two separate but interrelated topics:

1. Education about FOSS - turning students into FOSS contributors 2. Using FOSS in Education - tools, techniques, and stories.

Anyone interested in open source and education, at any level, discipline, and role, is welcome to participate.

Update: Our BoF has been accepted! It will be at 19:00 on July 19 (Monday).

Attendees:

[edit] Overview

This track covers two separate but interrelated topics:

  1. Education about FOSS
  2. Using FOSS in Education

[edit] Track proposal

We are proposing an Education Track for OSCON 2010.

Our proposals are referenced in #Submissions status.

Most proposals have the "Education" tag associated with it, and may have a link back to this page in the "Additional notes" section.

[edit] Submissions status

Topic/Title Type Owner Status
#POSSE presentation or panel Mel Chua Rejected
#Sugar Labs (Sugar on a Stick) presentation Sebastian Dziallas, Mel Chua Rejected
#Teaching FOSS to Undergraduates panel Ralph Morelli Rejected
#Opportunities for students to contribute to FOSS projects presentation Heidi Ellis, Greg Hislop Accepted
#5 FOSS in Edu projects that changed the world presentation Karsten Wade Waitlisted
#The Secret Lives of Computing Faculty in Higher Education presentation Matt Jadud Not Accepted
#Projects-Challenges-and-Opportunities presentation or panel Mukkai Krishnamoorthy (RPI) Rejected
#OLPC: The Trojan Horse to Open Source at Rochester Institute of Technology presentation Stephen Jacobs (RIT) Rejected
#Educating the next generation of FOSS developers presentation or panel Luis Ibanez Accepted
#open source course at Carnegie Mellon Silicon Valley presentation Tony Wasserman Submitted
#Can Open Source Save The World? Presentation Bryant Patten Accepted
#How to Describe Open-Source Fundamentals to your Uncle Fred Group Discussion Jeff Osier-Mixon Submitted
#Teaching Open-Source Documentation Group Discussion Jeff Osier-Mixon, Karsten Wade Submitted
#Junior Jobs and Bite-sized bugs: Entry points for new contributors to open source presentation Asheesh Laroia, Mel Chua Accepted
#Hard conversations: HOWTO assess performance in distributed FOSS organizations, and why and #How to connect student projects to FOSS junior jobs (merged) presentation Sumana Harihareswara and Luis Ibanez Submitted

[edit] Game plan

We put together the track as follows:

  1. We used the paper submission process to enter the proposal, using the 'Additional Notes' method, including a link to our central page in "Additional Notes" and putting "Education" in the tags field.
  2. We coordinated on this wiki page by listing our talk titles and abstracts below, and tracking status in a table.
  3. Simultaneously, we emailed oscon-idea at oreilly dotcom with a pointer at the proposal and an invitation to talk with some of us about the idea soonest.


[edit] Abstracts

[edit] POSSE

Title: Teaching Open Source Has A POSSE (Professors Open Source Summer Experience)

Description: How can professors learn to teach their students how to contribute to open source communities? POSSE is a one-week summer bootcamp program designed to teach just that - the art of being "productively lost."

Topics: Fundamentals, community

Session type: 40-minute Presentation

Abstract:

There are more professors than ever hoping to teach the open source development process to their students -- but working in the open source world can be a daunting proposition. Professors themselves have only a limited amount of time to learn about open source, and are often unsure about how, exactly, to get started.

POSSE (Professors' Open Source Summer Experience) is designed for these professors. Sponsored by Red Hat, the POSSE program is a weeklong bootcamp that will immerse professors in open source projects. Participants spend a week of intensive participation in selected open source projects, led by professors with experience in teaching open source development, in partnership with community members who have deep experience and insight. By the end of the session, participants should have a much better understanding of the workings of open source projects, and a strong network of contacts to lean on as they begin to bring students into the open source world.

This talk will cover the POSSE program's 1-year anniversary (we ran the first session in July 2009) and what we - and our alumni - have learned in our first school year of applying POSSE's lessons to teaching open source for the first time in an university. We will also include an update on the POSSE sessions currently running during the summer of 2010, and talk about how you can organize your own POSSE. More information about the program is available at http://teachingopensource.org/POSSE.

[edit] Junior Jobs and Bite-sized bugs: Entry points for new contributors to open source

Description (400 chars)

"Turn someone else's problems into your learning material." How do you expose your project's bugs and tasks to enthusiastic new contributors? We'll be talking about how OpenHatch's software tools and process-creating guidance make it possible to reveal a FOSS project's bug and task needs to budding contributors, students, and educators creating and running FOSS courses.

Abstract:

It's the chicken-and-egg problem of FOSS projects - there are always bite-sized work bits to do, and no way to tell new contributors how to even know about those needs. New contributors (or their teachers) want to see in to a project and find how they (or their students) can begin helping in small ways, but they need a full roadmap to find their way to a small problem they can solve. At the same time, the open source community is powerful, yet fragmented, with nearly one-fifth of open source developers knowing no one else who works on open source - and therefore no one else who they can reach out to for help.

In other words, one of the biggest problems educators and students have working with upstream FOSS project is that the projects they'd like to work with do not know how to expose their needs (tasks, bugs, etc.) in a way that is meaningful and useful to students. One solution that's sprung up to address this problem is the idea of junior jobs, a.k.a. bite-sized bugs. Projects such as Miro, Ubuntu, KDE, and GNOME have been tagging tasks that are good starting points for newcomers.

But bite-sized bugs are more than just a technical problem - there's a community stewardship aspect to them as well. Once the bite-sized tasks are labeled, how can new contributors find them? How can you make sure enthusiastic documentation writers see your call for help?

Our solution: OpenHatch is a community website where you can say what your project needs and what help you're willing to provide. We crawl bug trackers and highlight opportunities to work on bite-sized bugs in a way that's easily findable. For instance, you can browse by the programming language of the project, the kind of help needed, and the age of the request. By serving as a meet-market for these opportunities to get involved, we can not only help new contributors find things to do, but ensure that they know how to get in touch with the project - and stay in touch with it - as they progress.

Using the concepts, tools, and process of OpenHatch, this talk shows you how to request new contributors for your project, find new people to work with, and help them learn how to help you.

topics: trends, community, tools & techniques

[edit] Teaching FOSS to Undergraduates

Description: A panel discussion on teaching FOSS to undergraduates -- descriptions of courses at various levels, what should/should not be taught, what works and what doesn't work.

Topics: Trends, Community

Abstract: Computing instructors are beginning to experiment with teaching FOSS and teaching about FOSS to undergraduates. This panel discussion will describe efforts to teach FOSS at various levels of the undergraduate curriculum, ranging from introducing the concepts of free software and open source software to non-computing students in CS0 courses, to teaching the tools of the trade in upper-level programming and software development courses, to getting students engaged in real FOSS communities through capstone courses, independent studies, and research internships. The panelists will include representatives from industry and college instructors who will summarize how FOSS is being taught in higher ed and discuss what should be taught in FOSS courses, what works, and what doesn't work.

Additional Notes: This panel proposal will be part of the TeachingOpenSource.org Education track proposal: http://teachingopensource.org/index.php/OSCON_2010#Track_proposal

Speakers:

  • Mel Chua, Red Hat
  • Carlos Jensen, Oregon State University
  • Timothy Budd, Oregon State University
  • Luis Ibanez, Kitware Inc, Rensselaer Polytechnic Institute
  • Ralph Morelli, Trinity College, Humanitarian FOSS Project
  • Leslie Hawthorn, Open Source Office, Google
  • IBM

[edit] Opportunities for students to contribute to FOSS projects

Student contribution to open source software projects has great potential to benefit both the projects and the students. While it may take some effort on the part of the OSS community to bring students up to speed, students bring many advantages to the table including a larger pool of volunteers, a potentially more diverse development community, relieving more experienced developers from repetitive tasks, and added incentive to complete tasks due to grading requirements. In addition, students are supported in their participation by the academic infrastructure so that they are not relying solely on the OSS community for learning. OSS projects can serve as a training ground for future OSS developers, integrating students into the OSS community while still in school.

Open source provides an exciting opportunity for computing education by providing a range of different types of projects that students can become involved in. The benefits of participation in OSS projects are myriad for the student including exposure to an on-going, complex application, professional growth, improved technical and communication skills, better understanding of development in a distributed environment and many more.

The typical view of student contributions to OSS projects is in the form of code contributions. However, students with a range of backgrounds can contribute to an OSS project in ways other than adding code. Some of these ways include testing, documentation, bug validation, internationalization/translation of documentation, exploring and detailing feature requests, usability assessment, accessibility assessment, penetration assessment and reverse engineering requirements and design from code.

In order to facilitate the involvement of students in OSS projects, there is a need for identifying and recruiting mentors from the OSS projects. Such mentors would provide a gateway into OSS projects for both students and professors by supplying entree into the development environment and community. An online clearinghouse would be an ideal solution for matching students and opportunities posted by mentors and maintainers of OSS projects.

This talk will cover the dual perspectives of student and OSS community with respect to student contributions to OSS projects. The variety of different ways that students can become involved in a OSS project will be discussed as well as the benefits and roadblocks to student involvement from both perspectives. The talk will also address the "fit" of student expectation and skills with the OSS community needs and expectations. The intended audience for this talk is OSS developers and project leaders and academics interested in involving students in OSS.

[edit] How to connect student projects to FOSS junior jobs

Connecting students with FOSS projects in an effective and constructive way is critical both for the proper FOSS education of the students, and for the continued maintenance of these FOSS projects. In this panel we will share experiences on how class projects has been managed when teaching FOSS courses, and will be looking for suggestions and advice on how to better connect FOSS projects with students who are interested in joining their communities.

When sharing experiences among educators who have taught open source courses, one of the topics that is raised over and over again is the challenge of engaging students in existing open source projects. In an ideal scenario, we want students to find worthwhile tasks that can be accomplished in the short period of a one-semester course. There are multiple components to this challenge:

(a) consistent with an open source philosophy we want to allow student to chose the projects that the want to contribute to, instead of forcing a project on them. This however means too that students are left on their own to find their way into a project, by searching for a mentor with the necessary skills, patience, and time availability required to help them do something useful and interesting in the span of a couple of months.

(b) Students have disparate backgrounds and diverse software skills. We tend to emphasize that an open source course is not a programming course per se, (not the time for learning a new programming language) therefore we are restricted to the current skill level of students, as well as to their familiarity with standard software development tools such as revision control systems (git, svn, cvs, hg...), quality control dashboards, mailing lists, forums, wikis, and bug trackers.

It will be ideal to count with an on-line system where many open source projects could post tasks that they have identified as useful and easy (low hanging fruit), and for which a clear list of required skills are listed (programming language, domain knowledge). With such a system in place, students could find projects in the first days of the course, and therefore will be able to have a more effective exposure to open source community participation.

Evaluating the experience, both from the point of view of the student and from the point of view of the project is also a challenge. A large portion of this responsibility would fall on the shoulders of the mentors that guide the student through the project. Unfortunately, in most cases, the instructors are disconnected from the mentors and from the actual project in question, and are restricted to hear the reports from students.

[edit] 5 FOSS in Edu projects that changed the world

Proposal at 5 FOSS in Edu projects that changed the world - OSCON 2010.

[edit] OLPC: The Trojan Horse to Open Source at Rochester Institute of Technology

The following was submitted several weeks ago as an independent proposal under the community track. Could be part of The track as well or instead of a stand-alone depending on what happens...

In January, 2009 Rochester Institute of Technology’s Lab for Technological Literacy and Department of Interactive Media and Games began an experiment in service learning around the One Laptop Per Child and Sugar Labs Open Source Development Communities. A local OLPC User’s group was formed to support a seminar in Software Development for the OLPC/Sugar platform.

The class teaches the Open Source Software Development Process with the goal of supporting the Sugar Lab’s Math 4 effort to create games and teaching materials to support 4th grade math curricula. It also introduces students to the history of intellectual property protection, the Free Software and Open Source Software communities and movements, concepts in child development, educational software development, user testing, issues in software globalization and more.

Over the 18 months the course has been developed and offered, students have had the opportunity to interact with local and regional developers as the monthly user group meetings are integrated into the course. They also work in the international community of Open Source Developers who create software for the OLPC/Sugar platform.

Students who do well, and end the course with solid projects, can go on to pursue Co-Ops with Sugar Labs to continue their work. Some students in the winter quarter 2010 course have elected to pursue projects initiated in the Fall 2009 section. The initial 2009 student developers have joined the 2010 class on their own time to team with the new crop of students who are extending their work. One particularly motivated student has been a member of the original student cohort, worked a Co-Op position with Sugar Labs and supported other offerings of the course as a Teaching Assistant.

A new Co-Op project, outside of the class, has been funded by PEN International to support a version of the Sugar Video Chat Activity to make it more supportive of Sign Language and Deaf Students. RIT's Computer Science House is now hosting Sugar Lab's Activity servers.

The course is one of the few that teaches the Open Source Development process and perhaps the only one that has built a successful community ecology that brings former students and local community members in to the classroom. As such it has garnered attention from the Teaching Open Source (TOS) and Humanitarian Free and Open Source Software (HFOSS) communities. The success of this particular "Town and Gown" relationship has also brought speakers including Richard Stallman and Walter Bender to RIT and allowed the University to host events such as POSSE and FOSCon.

This presentation will document the RIT history and offer a model for its replication.

[edit] Endorse a white paper on the importance of FOSS in education

How:

Writing sprint. (Can fit into our overall proposal as a pre-conference activity, scheduled in the tutorial days, or as a sprint during the actual conference. First may make more sense as we might divie our potential audience if we have them choose between these and sessions)

Goal:

Get FOSS companies to write and/or endorse a white paper on the importance of FOSS Education for all computing majors (CE, CS, IS, IT, and SE). Such document will be a great help for Professors who need to raise awareness with the administration of their own institutions.


Abstrac:

This white paper will cover two main aspects of the interaction between FOSS and education.

A) What companies needs from recent graduates:

A.1) With current curricula in CE, EE, CS, students do not get enough exposure to concepts and practices that are essential for their professional success in the job market. In particular, students normally do not get to learn about: copyright, patents, trademarks, revision control system, quality control practices and distributed development teams. Few students have had a chance to work with a software project longer than a couple hundred lines of code, since most of their teaching involves only classroom and homework exercises. When students learn about these topics it is mostly through informal extra-curricular activities and via exchanges with peers. As a consequence, many of them hit the job market with a background that is insufficient for making them productive without extensive training in the job position itself.

A.2) As open source tools become the standard of use in many fields, it is vital for any company that runs an IT department, to have employees who are knowledgeable on the technical use of the tools, their legal framework, and the interaction with the communities that develop and maintain the tools.


B) What students need from FOSS tools

Proprietary tools are counter-productive in education. Most campuses offer to students collections of proprietary packages at very low-prices. The companies that provide these packages obviously do so with the clear intent of keeping these students as their future customers once they graduate, at which point they will have to pay the standard prices for those products. In this arrangement however, students are still subject to the abusive restrictions that are typical of proprietary products. The two of such conditions that are most opposed to education are: the prohibition for reverse engineering and the prohibition for publicly disclosing benchmarks and comparisons. When using proprietary tools a student will never be able to see first hand how is that a compiler works internally, the same goes for a web browser, a music streaming package, an operating system, a video editing tool, a scientific computation package, or an email client. In order to be compatible with the educational mission of colleges and universities, it is essential for FOSS tools to be used as the standard of practice in academic environments. Only FOSS tools allow and encourage students to see the internal implementation, discuss it publicly, modify it, thinker with it and share the results of their tinkering with their peers.

[edit] The Secret Lives of Computing Faculty in Higher Education

Title: The Secret Lives of Computing Faculty in Higher Education

Categories: Community, Trends

Abstract: This presentation will introduce open source practitioners to the secret lives of computing faculty in higher education. We will introduce the kinds of students we teach, the curricula we teach to, and the metrics by which we are evaluated (in terms of both teaching and research). Our goal is to provide some background for FOSS practitioners regarding the professional lives of faculty, closing with suggestions regarding how members open communities can best structure their projects to encourage collaboration and engagement with computing educators and their students.

[edit] Projects-Challenges-and-Opportunities

The Rensselaer Center for Open Source Software encourages freshmen and sophomore students to get involved in open source software projects. By enticing the students at an early age, there is a possibility of many of them get involved in open source projects. Since Rensselaer is primarily a technical university, many incoming students have a considerable prior knowledge of computers and their workings. Most of Rensselaer students have a technical bent. Also a few students have the sophistication to work on kernel level. Many more can work on building clever system and application level software. Many more build web applications. Thus these students can participate in a wide variety of software and hardware projects. In this talk, we will describe our experiences in running students projects in Rensselaer Center for Open Source Software. We will present the challenges we face and the opportunities that we have to make an impact in the Open Source World through Education.

Challenges:

1) The center needs to have a focus so that many students work on a project related to the mission of the center. Right now the focus is more open ended.

2) Many students, even those with very sound computer skills have difficulty choosing a project that will allow them to succeed.

3) There is no sufficient mentoring to all the students working in the center because of the diversity of projects and limited number of faculty members involved.

4) To sustain the center by seeking external support.

Opportunities:

1) Distinguished alumnus has generously started and supported the center. Many alumni see the need for open source software development and support the center indirectly. A few companies support the center by giving prize money to programming competitions.

2) Local non-government organizations, city and state government people come to give presentations about open source and to encourage students to get involved in open source software projects.

3) We have guest lectures by people from relevant industries and attempt to get the whole campus aware of the open source movement.

4) In three years since the start, a few students have done development that has gained national prominence.

5) We are able to offer a 4-credit (junior/senior) course on open source software systems.

[edit] Educating the next generation of FOSS developers

For three years now, Kitware and Rensselaer have collaborated in offering a course on Open Source Software Practices. The focus of this course is to provide students with a solid background in three main areas: (1) Laws and software, (2) Economics and collaborative means of production, (3) Social implications, and (4) Software engineering practices. The course therefore covers in depth topics on copyright, patents, trademarks, collaboration platforms, business models, social freedom, and community participation. Students get practical experience in practices of test-driven development, agile development and participation in distributed teams.

As part of the course, students are required to participate and contribute to an open source project. They have the option of starting a project from scratch or to join an existing project. The guiding principle of the course is to empower students to find their own way in the prolific environment of open source communities, by giving them a background that will allow them to make educated decisions along the way.

The course has been taught in collaboration between Kitware developers who have decades of experience in open source software development and community building, and Rensselaer faculty who enrich the course with their pedagogical point of view.

| OSCON 2010/Educating the next generation of FOSS developers


[edit] Can Open Source Save The World?

... or at least the part of it we call K-12 education? Schools all over the U.S. are desperately seeking ways to provide students with technology education, collaborative team skills and experience with real world problems. This comes at a time when school must justify every dollar spent. From UDL to differentiated learning, the Open Source community and its collaborative, cross-cultural method of creating software, hardware and data is a natural model for the requested transformation of U.S. K-12 schools. Schools are slowly recognizing the value of integrating FOSS solutions and methods but if the Open Source community actively reached out to schools, the transformation might happen a generation earlier.

This talk is targeted at FOSS project leaders and community members and will explain how our skills, knowledge and experience can be invaluable to educators in our home towns. Linux is definitely ready for the desktop. It is just a smaller desk than we expected.

[edit] How to Describe Open-Source Fundamentals to your Uncle Fred

Description: This group discussion is for open-source software advocates and developers who have a deep understanding of technical issues but become frustrated when describing these issues to non-technical listeners.

Abstract: Have you ever had to explain what "open source" or "free software" means to someone who is perhaps politely interested but not knowledgeable about the subject? This group discussion is for open-source software advocates and developers who have a deep understanding of technical issues but become frustrated when describing these issues to non-technical listeners. Special attention will be paid to enhancing listening and communication skills as well as practical strategies for dealing with the less-informed (including the press).

[edit] Teaching Open-Source Documentation

Description/Abstract: Do you teach technical writing? One way to give your students hands-on experience is to involve them in documenting open-source projects. This is a win for the student as well as for the project. This presentation describes methods for enabling teachers to use FOSS to bridge the gap between academic exercise and real-world production.

[edit] Hard conversations: HOWTO assess performance in distributed FOSS organizations, and why

Description: How can you manage performance in a distributed, open source organization without being a pointy-haired boss? This is your chance to engineer hard conversations, read (and write) the company's culture, and help engineers bootstrap their own personal & professional growth.

Abstract:

If we all were angels, we'd have no need of government -- or of a performance appraisal structure. Performance assessments provide a structure for helping us have those awkward conversations we need in order to grow. This is especially hard when:

  • everyone involved is a techie without management training
  • people rarely see each other face-to-face
  • the work is open source, especially R&D, with vague goals and deliverables

How can you ensure that your organization consistently provides for appropriate praise & criticism, and builds personnel files to help performers grow? I describe a schedule, architecture, and guidelines for performance appraisal, suitable for an open source distributed organization, as implemented at my previous firm.

Some key components:

  • Flat, top-down metrics like lines of code are destined to fail. Use this opportunity to get buy-in -- read and write the company's culture. Your most ninja rockstar developer may be down on herself for spending so much time mentoring others instead of generating code, or a prima donna may think it's beneath him to write documentation or test cases. These misalignments pop up in distributed workforces more frequently; address them systematically.
  • Self- and peer evaluations should balance length and ease of use (I suggest some usability guidelines and quantitative and qualitative choices).
  • Benchmark to help everyone understand the company's expectations, and to get everyone on the same page. Multiple criteria and concrete examples for each criterion show that the organization values mentorship, open source citizenship, collegiality, and initiative as well as raw coding skill.
  • Scrum-style conversations: a liaison regularly asks what you have accomplished, what you aim to do next, and what the organization can help you (fix blockers).
  • Confidentiality is key. I suggest access control rules and a separation of responsibilities among employees/contractors, managers, and evaluators.
  • I suggest how to responsibly gather performance feedback from external reviewers, including open source peers and clients.

You will get astounding rewards from appropriate, consistent criticism and praise of a worker's performance. It's difficult but it's worth it, and I'll show you how to make sure your whole organization benefits.

[edit] Participants

[edit] Potential attendees

If our track/talks get accepted, we should be hitting up these places/groups to let them know there'll be an education track at OSCON, and that they should attend/represent.

  • Carnegie Mellon Open Source Lab
  • Seneca College
  • Trinity
  • OLPC
  • Sugar Labs
  • RPI
  • University of Oregon
  • University of Puget Sound
  • UC Berkeley (BSD)
  • K12 open minds crowd
  • San Francisco State University
  • Please add here....

[edit] Confirmed interest

These individuals have actively helped with putting the track together (for the most part, contributing by submitting proposals and helping others get their proposals submitted). Please feel free to add your name to the list - make sure we have a way to contact you!

  • Luis Ibanez - Kitware
  • Ralph Morelli - HFOSS
  • Heidi Ellis - Western New England College
  • Gregory Hislop - Drexel University
  • Stephen Jacobs - RIT Specific interest in the 3 panels on courses, student contribution and 5 OSS projects
  • Karlie Robinson - OnDisk
  • Karsten Wade - Red Hat
  • Mel Chua - Red Hat
  • Matt Jadud, Allegheny College
  • Alolita Sharma - Open Source Initiative (OSI)
  • Sameer Verma - San Francisco State University
  • Carlos Jensen - Oregon State University
  • Jeff Sheltren - Open Source Lab @ Oregon State University
  • Bryant Patten - The National Center for Open Source and Education - [1]
  • Jeff Osier-Mixon - developer advocate, blogger, MontaVista technical writer & community mgr - [2]

[edit] Submission Process

[edit] Get an O'Reilly Login

https://en.oreilly.com/oscon2010/user/account/signup

https://en.oreilly.com/oscon2010/user/account/create/user

You need for this

  1. Email
  2. Bio

[edit] Format

Use the OSCON 2010 template to fill in your details, referring back to this section or the CFP page for the topic list. Do not forget to use the "Education" tag in the field provided

Go to this page to submit your proposal:

http://en.oreilly.com/oscon2010/user/proposal/propose/cfp/92

You need:

  1. Title
  2. Description (brief overview for marketing purposes, max. length 400 characters—about 65 words)
  3. Pick one of these topics
    1. Administration
    2. Business
    3. Cloud Computing
    4. Databases
    5. Design & Usability
    6. Trends
    7. Fundamentals
    8. Government
    9. Legal
    10. Linux
    11. Java
    12. Operating Systems
    13. Mobile
    14. Community
    15. Perl
    16. PHP
    17. Programming Languages
    18. Tools & Techniques
    19. Python
    20. Ruby
  4. Pick a Session Type
    1. 40-minute Presentation
    2. 40-minute Group Discussion
    3. 40-minute Panel
    4. 3-hours Tutorial
  5. Abstract (there are not specific guidelines here, but they suggest to look at these third party sites for advice).
    1. http://datacharmer.blogspot.com/2008/09/how-to-get-your-proposal-accepted-to.html
    2. http://www.xaprb.com/blog/2007/10/05/how-to-get-your-session-accepted-to-mysql-conference-2008/
    3. http://www.bytebot.net/blog/archives/2007/10/25/mysql-conference-2008-cfp-review-my-list-of-10
    4. http://alex.dojotoolkit.org/2009/02/some-oscon-proposal-tips/
    5. http://blog.web2expo.com/2008/04/how-to-write-a-successful-speaking-proposal/
    6. http://radar.oreilly.com/2009/05/last-chance-submit-a-talk-for-1.html
    7. More Advice: in the section : "Some tips for writing a good proposal for a good talk:" of http://en.oreilly.com/oscon2010/public/cfp/92
  6. Pick an Audience Level
    1. Novice
    2. Intermediate
    3. Expert
  7. Additional Notes :
    1. Any other information you wish the organizer to know? If you are proposing a workshop, please tell us what type of learning experience you have in mind (hands-on, demo, etc.). If you selected “Other” in the Session type field, please provide more details here.
  8. Provide any related tags to your presentation ( comma separated list )
    1. IMPORTANT: To be part of our common track add the tag: "Education"
  9. Finally: Add One or More Speakers

[edit] Examples Abstracts from OSCON 2009

  1. "New Ways for Teaching Children Software Programming"
    1. http://en.oreilly.com/oscon2009/public/schedule/detail/7593
  1. "Educating Students in 21st Century Skills via FOSS"
    1. http://en.oreilly.com/oscon2009/public/schedule/detail/8138