PA05 - Project Ranking and Selection

Introduction

Through the Candidate Projects, Project Explorations and Project Reviews assignments you have all gained a great deal of familiarity with a wide variety of H/FOSS projects. This assignment asks you to form a project team, make a direct comparison between a number of the projects in which the team is interested, and based on that comparison select the H/FOSS project on which the team will work for the year.

Team Formation

Your instructor will use the information from the explorations and reviews that have been posted on the course repository to identify areas of common interest across the class. During class time, these areas will be presented with a list of representative projects. Individuals will indicate their interest in working on a team in the different areas. We as a class will then negotiate the exact composition of each project team such that everyone has been placed on a team in which they have some shared interest. Each team will have between 2 and 5 members and an effort will be made to keep the total number of teams in the class to 4 or less. Keep in mind that during the actual project work, teams may divide into smaller groups (sub-teams of two or three) as appropriate to work on different aspects of the same H/FOSS project. It is also possible that multiple teams will be independently selecting a project from the same area.

Running Team Discussions

Team discussions can be challenging. Without some structure a few voices can dominate conversations causing the team to miss out on other valuable perspectives. This section, provides a few tips for running team discussions that will be helpful in this assignment, but also may serve your team well throughout the course.

In all discussions, the team must ensure that every team member has equal opportunity to be heard and understood. Every team member should be given the opportunity to speak uninterrupted about the topic being discussed. Other teammates should listen actively and may ask clarifying questions, but must refrain from giving opinions, arguing or debating the points being made. They may do those things when it is their turn to speak. The Talking Stick method is a simple but effective way to manage such a discussion.

In discussions where a decision is to be made further discussion will be needed following the opportunity for each team member to speak. All team members should have equal voice in this discussion as well The fist-to-five method is a simple but effective way to quickly gauge support (or lack of support) for a decision. It can improve the efficiency of discussions by shortening them when there is broad consensus and focusing them on areas of disagreement when there is not. When there are multiple alternatives for a decision eliminating the options with the least support can helpful in forming consensus around other options. For particularly contentious decisions ranked choice voting and anonymous voting systems such as Mentimeter can be helpful.

Assignment

Once the teams have been formed, each team will complete the Ranking and Selection activities below in order to choose the project on which they will work. There will be one submission for this assignment for each project team. The submission must be completed collaboratively with the involvement of all team members.

To complete this assignment:

Determine at least two one-hour blocks during the week when all members of the team can meet to hold out-of-class meetings. Finding common times can be difficult. Using a tool like When2meet can facilitate this process. 2.Create a GitHub Organization for your team:
1. Invite all teammates to join the organization a an “Owner.”
2. Fork the course repository into the organization.
3. Create a feature branch for the team’s work
4. Create a directory for your team in the teams directory.
5. Create a README.md file in your team’s directory.
6. Copy the ProjectSelection.md file in the teams directory into your team’s folder.
7. Compete the following tasks to add content to your team’s README.md
  1. Add a top level heading to the README.md containing the the text “Our Team”.
  2. Add a second level heading for “Team Members” followed by a list with the names of all team members that link to their individual README.md files.
  3. Add a second level heading for “Meeting Times” followed by at least two times outside of class time that all members of the team are available to meet.
  4. Add a second level heading for “Project Documents”.
  5. Add a bullet to the “Project Documents” section that links to the team’s copy of ProjectSelection.md file in your team’s folder.
8. Complete the following tasks to add content to the team’s ProjectSelection.md document for this assignment.
  1. Complete the Projects Considered section below.
  2. Complete the Install Spike section below.
  3. Complete the Project Rating section below.
  4. Complete the Project Selection section below.
  5. Choose a name for the team and update the “Our Team” top level heading in the README.md file to be the team’s name.
9. Create a PR to the upstream course repo containing the team’s work for this assignment.

Projects Considered

Hold a team discussion to decide on 3-4 projects that the team will consider for selection as their project for the year. Teams should not consider projects that have not been reviewed by at least one of the team’s members. This discussion should last no more than 1 hour.

It is suggested that all team members re-read the explorations and reviews (theirs and others) for the projects that they are personally interested in considering. This will help in brining concrete information supporting opinions to the discussion.

When the team has decided on the projects it will consider, edit your team’s ProjectSelection.md file to give information about each of the projects.

For each project that the team is considering for selection:

Edit one of the bullets in the “Projects Considered” section.
Add links to of all of the Project Explorations and Project Reviews that were completed (including those not done by your classmates). You can find these links on the Project Explorations and Project Reviews pages in the Course Repository.

Note, the team may find that as its discussion progress it makes sense to come back and consider different or additional projects. That is perfectly acceptable, just add them to the list accordingly.

Install Spike

As a part of the Project Explorations and Project Reviews the team members have looked at the documentation for installing, running and working on these projects. However, it is often not until you really attempt to install and work on the project that it becomes clear how helpful (or not) this documentation actually is. The spike in this section will help the team to more fully evaluate how easy or how difficult it might be to get started as a developer with the project.

For each project being considered:

Update one of the “Project Name” subsections in the “Install Spike” section of your team’s ProjectReviews.md file.
Assign a sub-set of the team’s members to be responsible for the install spike for that project.
The sub-set of team members assigned to each project will then complete the Developer Perspective Spike for the project as described below.

Developer Perspective Spike

The purpose of this spike is to get a feel for what it will be like to get setup to contribute to this project. You will want to find the directions that the project provides for getting set up to modify the code of the project. This will definitely require forking and cloning the project repository, among other steps. Often projects will have documents about “getting started”, “how to contribute”, “developer install”, or something similar. The INSTALL.md file will usually get you started, but you may need to dig around a little to find all of the appropriate documentation. If you are having difficulty finding the relevant information for your project consider asking the community for help and/or seeing your instructor for assistance.

To complete the Developer Perspective Spike:

Spend a maximum of 4 hours trying to install the development environment and getting the product to build and run from the source code. Ideally you will also be able to make a change in the source code and observe the effect in the running product. If you are unable to install the development environment, and build and run the product from the source code within 4 hours stop.
In the “Install Spike” section for the project, update the “Developer Install Spike” information by:
1. Adding links to any “Installation Documents” that you found useful when attempting to install/build/run the product from the source code.
2. Adding links to your fork and the project’s upstream repository to the “Repository Links” bullet.
3. Adding a “Summary” paragraph summarizing your experience trying to install/build/run the program as a developer. Your summary should include information about whether you were successful or not in installing/building/running the program, your assessment of the quality of the documentation that you used, how difficult you found it to install/build/run the program, any assistance you received from the community, and a discussion of any difficulties you experienced.

Project Ratings

Once the team has completed the Install Spike, it will create ratings for the projects being considered. Information including the Project Explorations, Project Reviews, the Install Spikes, and the team members’ backgrounds and interests will factor into these ratings.

To complete the Project Ratings:

Replace P1, P2, P3, … in the “Project Name” column in the table in the “Project Ratings” section with the names of the projects your team is considering. Add additional rows to the table as necessary.
Engage in a full team discussion of the Project Explorations, Project Reviews, Install Spike and any other information you find useful to come to a consensus ranking for the projects along each of the dimensions described below. Before beginning this discussion all team members should re-read their explorations and reviews for any of the projects under consideration. If a team member did not explore or review a project they should read a review done by someone else in the class.
- Community: How would it be to work within this project’s community? Consider issues including the size and diversity of the user and developer communities, the availability and variety of communication channels, the quality and tone of communications, and how the community treats and on-boards newcomers.
- Complexity: How technically hard is it going to be to work on this project? Consider issues including your ability to grasp the overall purpose and organization of the project, size of the code base, the number of different tools/languages/technologies/frameworks used, the quality of documentation, and the modularity of the project (i.e. will you be able to isolate what you have to know?).
- Activity: How active is this project? Consider issues including the recent responsiveness of community members in the communication channels, the rate at which the code is changing (is it too slow or too fast?), whether new issues are being opened, commented on and closed, whether pull requests are receiving feedback and being merged, and how up to date the documentations is.
- Approachability: How hard would it be to get started with this project? Consider issues including the quality of the getting started documentation for contributors, your experiences with the Install Spike, the number of new contributors that have contributed to the project recently, availability and understandability of good first issues, alignment of your team’s current skill set with the project’s tools/languages/technologies/frameworks, and the amount of domain knowledge required.
- Appeal: How interested is your team in this project? Consider issues including the application domain, the benefits to end users, the technologies employed, and the goals of the team members.
Complete the “Rationale” section by giving a paragraph for each dimension that summarizes the team’s rationale for the rankings in that dimension. The paragraph for each dimension should be comparative. It should use details from the team’s discussion of the Project Explorations, Project Reviews and the Install Spikes to make it clear why projects were ranked higher or lower than others on the dimension.

Project Selection

Engage in a full team discussion of the ratings and rationale that you produced in the prior section with the goal of selecting the project on which the team will work. The ratings are to help inform the team’s decision but it is not required that you simply choose the highest rated project. For example, the team might weigh some dimensions more heavily than others in its decision making.

When the team has selected a project complete the “Project Selection” section as follows:

Indicate the “Project” that the team selected.
Give a paragraph explaining the “Rationale” for the team’s choice. This should describe the team’s thinking, including how it considered the ratings, how heavily different dimensions were weighted, and why.
Review the team’s experiences with the Install Spike for the selected project and give a rough “Install Estimate,” with some justification, for how many hours it might take all team members to get the product up and running as a developer.
List, with a brief explanation, any “Knowledge Gaps” that the team thinks it has and that would be valuable to fill in before beginning work on this project. For example, gaining experience with the product, learning tools/languages/frameworks that the project uses, etc.
List, with a brief explanation, any additional “Concerns” that the team has about working on the selected project.

Acknowledgements

This assignment builds from and adapts ideas and content from the following activities created by others:

https://github.com/ChrisMurphyOnline/open-source-software-development-course/blob/master/activities/foss-evaluation-activity.txt
http://foss2serve.org/index.php/Project_Evaluation_Activity_V2

All textual materials used in this course are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License