Proposal for General Work by Students on OpenOffice.org

There are several spaces where OpenOffice.org can offer itself as a place for student intervention. For instance, a professor could structure a class on office suite construction around OpenOffice.org, or a class on application architecture; or on architecture revision. Because OpenOffice.org is open source, there are few limits.

This brief draft focuses on current development and suggests some processes by which students might profitably engage in the project while also satisfying the demands of their schools. Because it is a draft and not complete, I welcome emendations and additions.

• Key point is to set up a structure so that the students can work together in-class on tasks
• The professor can review and coach the student
• Interface with the project by a student leader
• Some students may wish to go it alone; that's fine; best for advanced students
• Lower-level students should work with "easy" tasks and with QA
• For QA, same situation: groups, group leader
• How is grading, checkup established?
• Ambition: if QA, then working on finding and reporting well-formed bug reports on various systems, components. The mission of each student project is determined by examining QA IssueZilla lists or in consultation with QA team (or with Sun QA team);
• If more advanced, then grade is determined by the stated ambition of handling open issues, tasks; students can work here jointly or independently. The to-dos list is one crucial list but there are others, too, for instance, IssueZilla searches, RFE lists, etc. In this regard then there is little difference here from regular school work, where a student must, say, determine, research, and write up a paper for a course grade
• Process: For an advanced course, where the focus is on learning some elements of C++ operations, the professor scans the to-dos list for plausible candidates; or we suggest them (probably the latter). We rate them, as difficult (needing several months, advanced); medium (a couple of months); easy. Students can take them on, explain what problem of programming these address, how this fits in with their overall coursework, and issue progress reports. These reports can complement the IssueZilla updates expected.
• If a student does not finish the task before she leaves the semester, then the task can be completed by others in the OSS community, by subsequent students, etc.
• Primary in this process is that the student learns how to work with others in an open-source, collaborative environment, with the relevant tools. Hence, the need for updates, so as to clarify the status of work, as well as who is working on it.
• Grading thus can be for the work done, its sophistication, etc., as well as for collaboration? No, unless student is directly interfacing with the community.
• What if the student thinks she does good work, the professor agrees but the OpenOffice.org developers disagree? That is they reject the patch. The professor should not let that affect grading. Acceptance is a plus, but purely extrinsic. Reason: otherwise, the OpenOffice.org developers would be in the odd position of grading student work.
• Grading finally: on what has been learned; perhaps then a report, a paper at the end. Such work could also encompass documentation of work.
• in the end, OpenOffice.org work should then complement key lessons. That is, if a student is learning C++, or architecture, the patch work can be seen as a way of implementing the lessons.
• Where can students find a list of to-dos? URL: http://development.openoffice.org/todo.html