RCOS is largely a self-guided class, which can make grading difficult. Instructors assign appropriate grades using utilities such as Observatory to track open source contributions and community involvement.
The following grading criteria are designed to help you succeed as an RCOS student and in the open source community. Generally speaking, if you're contributing to the community and/or making valuable open-source contributions you'll receive a high grade in RCOS.
Each project must start with a proposal which will serve as a plan and contract. Your proposal should describe a set of well defined milestones with planned dates of completion. Details on milestone requirements are described in the Milestones and Issues section.
The proposal and milestones must be approved by a mentor at the start of the semester. However, it is important to remember that the proposal is a living document. Plans often change, and that is OK.
You must use GitHub Milestones and Issues to define and track progress of your project.
Milestones are specific points along the project timeline. Milestones are designed to signal the start and end of phases of the project. Milestones are generally over-arching goals and should define the project's direction.
Issues are small increments of your project. They should have clear acceptance criteria, and should contain enough background information that someone completely new to the project could easily understand the task. Each issue should belong to a milestone. Common issue topics include but aren't limited to:
- New features
- Designs
- Research goals
- Architecture changes
- Project management tasks
- Business development
- Documentation
- Community outreach
- Testing
Project members must keep their milestones and issues up to date as the project progresses. This includes updating milestones and issues as the project evolves. Project members should comment on issues to ask questions, report progress, and have discussions regarding the issue.
Each team member should contribute to at least 3 milestones, and multiple team members can of course collaborate on any given milestone. These are suggested values and many groups may find different numbers to be appropriate.
Progress for each milestone must be thoroughly documented in one or more blog posts. See Blog Posts for more information. If a milestone is not a functional change, there should be a greater focus on documentation to appropriately convey the work that was done.
If you are not sure how to best divide up your project into milestones and issues, please ask a mentor for assistance.
Projects should be well documented. Documentation can take many forms. A README and an OSI approved license are mandatory. The README should include a summary of the project, instructions for contributing, and any other information needed to develop for and use the project.
Additional documentation (other than a README and blog posts) is required. Examples of additional documentation include but are not limited to:
- Business plans & reports
- UML diagrams
- API documents
- User manuals
- FAQs
- Setup guides
- Troubleshooting information
The use of a wiki is strongly encouraged. Creating a static project site can help you organize your various forms of documentation and provide excellent exposure for your project.
If you are unsure how to properly document your project, please consult your mentor for advice early on.
Blog posts should be informative, and are often status updates about your project. They can also be more general or written in the form of a guide or tutorial. Blog posts that may help another developer solve a problem that you have solved are extremely valuable to the open source community. In general you should write blog posts that you would want to read and that you would find useful!
Blog posts are also a good way to explain the high level goals of a project, to indicate that a project is struggling (someone in RCOS might be able to help!) or just to document tasks that don't fall easily into other categories.
The minimum requirement for blog posts is one per milestone plus one at the start and end of the semester, but you are strongly encouraged to do more. Blog early and blog often!
Each project group is required to give one large group presentation. Presentations should be well prepared and rehearsed in the presence of a mentor for feedback. See RCOS presentations for more details.
In addition to the large group project presentation, each member is required to either give one large group tech talk, host a bonus session, or alternatively attend a bonus session. A bonus session is simply any event hosted outside of the normal RCOS hours. Upperclassmen and more senior members are encouraged to give tech talks for the benefit of the RCOS community. All members are encouraged to attend bonus sessions. A bonus session attended in lieu of hosting a bonus session or giving a tech talk cannot also count as an attendence makeup.
Being part of the RCOS community means seeing what RCOS members are doing, giving feedback, and learning from tech talks and guest speakers. Attendence is required and is taken on Tuesdays and Fridays via Observatory.
Unexcused absences can be made up by attending bonus sessions. Generally bonus sessions are unique, long or workshop-style tech talks, an RCOS hackathon, or an optional RCOS session. Pay attention in the large group meeting to hear bonus sessions announced.
A student can have two unexcused absences before their grade is affected or make-ups are needed.
Contribute to something outside of RCOS or help out another group with an issue! External contributions are encouraged as it allows RCOS to give back to the larger open source community. The project you're contributing to should be used by a significant number of people outside of RPI.
Within RCOS, we also want to generate a community of helping other projects and making your project more friendly to outside contributors. If you're doing your external contributions to another RCOS project, it must be a project that you have not previouly worked on and you must communicate with the project through GitHub issues, PRs, and code reviews.
External contributions are strongly encouraged but are not required. With the approval of a mentor, a significant external contribution can take the place of a single milestone requirement.
Although RCOS is a team sport, grading is done on the individual member. Make sure you meet the requirements, including the requirements on the project itself such as the README, License and other forms of documentation.
If you find this rubric to be incompatible with your project, or you believe that it will significantly hinder or not accurately represent your progress, please let a coordinator or faculty member know as adjustments and exceptions can be made.
| Grade | Description |
|---|---|
| A | Makes meaningful contributions to several milestones. Student is active on GitHub and Slack and makes excellent use of issue tracking and project management systems. Student communicates failures and development barriers to their team and mentors, and makes their best effort to overcome challenges. |
| B | Makes meaningful contributions to several milestones, but may be slightly lacking in communication and/or planning requirements, or may not make good use of issue tracking / project management systems. |
| C | Makes too few contributions and does not ask for help when needed. Student makes little to no use of issue tracking and project management systems, and does not communicate well with team members or mentors. |
| D | Makes almost no meaningful contributions and makes little effort to communicate with team members and mentors. |
| F | Makes no visible effort to contribute to their project or communicate with their team and mentors. |
| Grade | Description |
|---|---|
| A | Makes frequent, high caliber blog posts documenting each issue they work on and several problems they solve. Project has an OSI approved license, a helpful README, has additional documentation that is of quality and value. |
| B | Makes blog posts that may be too few or brief OR project may not have may not have much additional documentation. |
| C | Makes only a few or low quality blog posts, OR project may have little other documentation. |
| D | Makes few blog posts of little to no value and does not contribute to other forms of documentation. |
| F | Makes no blog posts and contributes no effort toward documenting the project. Project does not have a meaningful README or license. |
| Grade | Description |
|---|---|
| A | Participates in large group presentation and demonstrates a knowledge of what they worked on; is well prepared and clearly rehearsed. Hosts a well prepared and useful tech talk or bonus session OR attends the requisite bonus session. |
| B | Makes a reasonable effort to participate in presentation and is at least somewhat prepared. Hosts a tech talk or bonus session OR attends the requisite bonus session. |
| C | Is unprepared for presentation or does not participate heavily. Hosts a tech talk or bonus session OR attends the requisite bonus session. |
| D | Makes little effort to participate in presentation and does not host tech talk, bonus session, or attend bonus sessions. |
| F | Makes no effort to participate in presentation or does not attend. Does not host tech talk, bonus session, or attend any bonus sessions. |
| Grade | Description |
|---|---|
| A | Misses no more than two meetings and makes up any unexcused absences by attending bonus sessions. |
| B | Attends most meetings and makes up most unexcused absences. |
| C | Repeatedly misses meetings or does not make up unexcused absences. |
| D | Misses many meetings and does not attempt to make up unexcused absences. |
| F | Makes no effort to regularly attend meetings. |