S&P: Standards & Practices
HFOSS Chapter Principles and Guidelines
The purpose of an HFOSS Chapter is to help revitalize undergraduate computing education at your school by introducing the principles and practices of FOSS into your instruction and curriculum. As a Chapter, you will collaborate with faculty and students at other HFOSS chapters in building free and open source software that benefits the public good.
The list below identifies the expectations that would accompany your becoming an HFOSS Chapter.
- At least one member of the computing faculty at your institution agrees to be the HFOSS Faculty Representative for the duration of your affiliation with the HFOSS project.
- The HFOSS Faculty Representative agrees to collaborate in H-FOSS software development activity with one or more undergraduate students.
- The HFOSS Chapter is expected to create a public website (H-FOSS@Chapter.edu) that links back to the main H-FOSS site (http://www.hfoss.org).
- The HFOSS Chapter is expected to participate in helping to build the CC-licensed HFOSS Repository (http://repository.hfoss.org), a repository of instructional materials by contributing course and teaching materials developed during the project to the repository.
- The HFOSS Chapter is expected to participate in periodic HFOSS Project evaluation activities.
- HFOSS Chapter participants may be asked to help with HFOSS project outreach by organizing or participating in a public lecture or similar activity in their city or region.
- HFOSS Chapters are encouraged to incorporate FOSS and HFOSS principles and practices into their curriculum in ways that are appropriate for their schools.e.g., introductory or advanced courses, capstone projects, etc.
- HFOSS Chapter participants are encouraged to participate in the HFOSS Certificate program, especially as to the fit with their curriculum.
If the HFOSS Chapter received NSF or other funds from the HFOSS Project:
HFOSS Seed Funding Round 2 (CLOSED): submitting this form (http://www.hfoss.org/ChapterApplication/) ,you are applying for financial support from the Humanitarian FOSS project to establish an HFOSS Chapter at your institution.
- H-FOSS chapter funds $15,000, which may be used to cover student and faculty stipends and some travel and outreach support, are to be disbursed as an NSF subcontract with the stipulation that no NSF funds may go toward institutional overhead costs. -->
- NSF funds provided to the HFOSS Chapter must be matched either directly or in-kind. -->
- The HFOSS Faculty Representative is expected to participate in an orientation and training activity organized by the HFOSS Project to occur during late May 2011. -
- HFOSS Chapter faculty and students are encouraged to present their work at the annual HFOSS Symposium, generally held as a pre-conference activity at the annual SIGCSE meeting.
- If the HFOSS Chapter received NSF funds, through the HFOSS Project (or two years, depending on the availability of funds), The HFOSS Chapter would be expected to seek their own means of funding, possibly in collaboration with HFOSS, if they wish to sustain their activities.
General Practices for Project Development and Management
The following are suggestions an best practices, used by teams in managing their HFOSS development efforts.
- All teams will be required to make weekly written reports of work carried out during the week and hold regular team code review sessions. (See Code Review Session Guidelines)
- All team members will be required to maintain daily logs of tasks for that day and report progress at end of day, to ensure projects stay on task, time and meet/exceed milestones, especially for those with hard deadlines!
- Think of reporting as a fun activity that will improve your overall productivity and workflow and not a requirement :-)
- Everyone on the development team should have worked on or agreed to a design prior to coding.
- All committed code should, where applicable, have corresponding unit tests to accompany the code. Without appropriate unit tests or justification, code should not be committed to primary development branches in repositories.
- Remember to test your code before committing.
- Always comment your code, such that another programmer can pick up where you left off or imaging yourself revisiting your program 6 months from now, trying to remember why you put that recurive call in etc..
- When committing, ALWAYS include SENSIBLE comments. Do NOT say "fixed bug X" or leave comments blank. Describe in full sentences.
- Follow the established coding practice for your specific project, if it's new project, agree upon some practices with your teammates.
Developer Scrum/Standup Meetings
- All team members are required to attend the daily scrum.
- The daily scrum is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken offline and usually dealt with by the relevant sub-group immediately after the daily scrum.
- During the daily scrum each team member provides answers to the following three questions:
- What did you do yesterday?
- What will you do today?
- Are there any impediments in your way?
- By focusing on what each person accomplished yesterday and will accomplish today the team gains an excellent understanding of what work has been done and what work remains.
- Teams are encouraged to hold daily scrum meetings no more than 15-20 minutes at a set time in the morning.
- Additional details about Scrum development
Contributor License Agreement
The Humanitarian FOSS (HFOSS) Project requires a Contributor License Agreement (CLA) to be signed and returned by HFOSS Participants in development projects, and requests them of anyone contributing their intellectual property (code or design requirements or ideas) to HFOSS project and it's affiliates ( 3rd Party projects may have their own CLA Agreements). This serves to protect everyone's rights and ensures HFOSS Project can legally and publicly redistribute code contributions.
The purpose of this agreement is to clearly define the terms under which intellectual property has been contributed to HFOSS and thereby allow us to defend the project should there be a legal dispute regarding the software at some future time. HFOSS committers will be responsible for ensuring that all code contributions come from only those who have signed a CLA before merging code into the trunk. (So if you don't sign and return a CLA, your code contributions will not become a part of the main development branch of the respective HFOSS Project nor will it be included in any releases from the HFOSS Project).