Skip to main content

GitKit (2nd ed.) Learn Git and GitHub in Context

Grant Braught, Lori Postner, Darci Burdge, Ruth Lamprecht, Stoney Jackson, Karl R. Wurst

Section 2.2 FOSS Communities

During class time you will have learned about the principles that guide FOSS Communities and the roles that are performed by FOSS community members. The exercises in this section ask about those principles and roles.
🔗

Subsection 2.2.1 FOSS Community Principles

Some of the key principles that guide FOSS communities are shared values, collaboration, transparency, inclusivity, meritocracy and release early and often.
🔗
If you would like you can review a discussion of these principles in the speaker notes in the slides for this chapter or in The Open Source Way.
🔗

Exercises

1.
Consider each of the following statements about the operation of a FOSS community and choose the principle (or principles if multiple apply equally) with which it most closely aligns.
🔗
(a)
By building on each other’s work the community can solve problems that no one could solve alone.
🔗
  • Shared values
  • It’s not shared values. Another principle is more closely related. Review the principles in The Open Source Way.
  • Collaboration
  • Working together to solve problems is at the heart of collaboration.
  • Transparency
  • It’s not transparency. Another principle is more closely related. Review the principles in The Open Source Way.
  • Inclusivity
  • It’s not inclusivity. Another principle is more closely related. Review the principles in The Open Source Way.
  • Meritocracy
  • It’s not meritocracy. Another principle is more closely related. Review the principles in The Open Source Way.
  • Release early and often.
  • It’s not release early and often. Another principle is more closely related. Review the principles in The Open Source Way.
Hint.
🔗
🔗
(b)
Decisions and the rationale for them are available to the community.
🔗
  • Shared values
  • It’s not shared values. Another principle is more closely related. Review the principles in The Open Source Way.
  • Collaboration
  • It’s not collaboration. Another principle is more closely related. Review the principles in The Open Source Way.
  • Transparency
  • Sharing decisions and rationale with the community allows everyone to know how and why decisions are reached.
  • Inclusivity
  • Sharing decisions and rationale allows everyone in the community to feel included.
  • Meritocracy
  • It’s not meritocracy. Another principle is more closely related. Review the principles in The Open Source Way.
  • Release early and often.
  • It’s not release early and often. Another principle is more closely related. Review the principles in The Open Source Way.
Hint.
🔗
🔗
(c)
The mission and goals of the community are more important than individual agendas.
🔗
  • Shared values
  • The goals are shared if they take precedence over individual agendas.
  • Collaboration
  • Shared goals of the community invite collaboration.
  • Transparency
  • It’s not transparency. Another principle is more closely related. Review the principles in The Open Source Way.
  • Inclusivity
  • It’s not inclusivity. Another principle is more closely related. Review the principles in The Open Source Way.
  • Meritocracy
  • It’s not meritocracy. Another principle is more closely related. Review the principles in The Open Source Way.
  • Release early and often.
  • It’s not release early and often. Another principle is more closely related. Review the principles in The Open Source Way.
Hint.
🔗
🔗
(d)
The best ideas should win, regardless of where they come from.
🔗
  • Shared values
  • It’s not shared values. Another principle is more closely related. Review the principles in The Open Source Way.
  • Collaboration
  • It’s not collaboration. Another principle is more closely related. Review the principles in The Open Source Way.
  • Transparency
  • It’s not transparency. Another principle is more closely related. Review the principles in The Open Source Way.
  • Inclusivity
  • Individuals feel included if their contributions are assessed on merit, not their own identity.
  • Meritocracy
  • Ideas and contributions should be assessed solely on merit.
  • Release early and often.
  • It’s not release early and often. Another principle is more closely related. Review the principles in The Open Source Way.
Hint.
🔗
🔗
(e)
Incorporating new changes and features quickly generates feedback and leads to rapid improvement.
🔗
  • Shared values
  • It’s not shared values. Another principle is more closely related. Review the principles in The Open Source Way.
  • Collaboration
  • It’s not collaboration. Another principle is more closely related. Review the principles in The Open Source Way.
  • Transparency
  • It’s not transparency. Another principle is more closely related. Review the principles in The Open Source Way.
  • Inclusivity
  • It’s not inclusivity. Another principle is more closely related. Review the principles in The Open Source Way.
  • Meritocracy
  • It’s not meritocracy. Another principle is more closely related. Review the principles in The Open Source Way.
  • Release early and often.
  • Releasing early and often allows the project to respond to needs quickly by gathering feedback.
Hint.
🔗
🔗
(f)
Community members enhance and extend what others contribute in unanticipated ways.
🔗
  • Shared values
  • It’s not shared values. Another principle is more closely related. Review the principles in The Open Source Way.
  • Collaboration
  • When we can modify what others have shared, we unlock new possibilities.
  • Transparency
  • It’s not transparency. Another principle is more closely related. Review the principles in The Open Source Way.
  • Inclusivity
  • It’s not inclusivity. Another principle is more closely related. Review the principles in The Open Source Way.
  • Meritocracy
  • It’s not meritocracy. Another principle is more closely related. Review the principles in The Open Source Way.
  • Release early and often.
  • It’s not release early and often. Another principle is more closely related. Review the principles in The Open Source Way.
Hint.
🔗
🔗
(g)
Decision makers continually seek diverse perspectives.
🔗
  • Shared values
  • It’s not shared values. Another principle is more closely related. Review the principles in The Open Source Way.
  • Collaboration
  • It’s not collaboration. Another principle is more closely related. Review the principles in The Open Source Way.
  • Transparency
  • It’s not transparency. Another principle is more closely related. Review the principles in The Open Source Way.
  • Inclusivity
  • Good ideas can come from anywhere.
  • Meritocracy
  • It’s not meritocracy. Another principle is more closely related. Review the principles in The Open Source Way.
  • Release early and often.
  • It’s not release early and often. Another principle is more closely related. Review the principles in The Open Source Way.
Hint.
🔗
🔗
(h)
All community members have access to the information necessary to do their best work.
🔗
  • Shared values
  • It’s not shared values. Another principle is more closely related. Review the principles in The Open Source Way.
  • Collaboration
  • It’s not collaboration. Another principle is more closely related. Review the principles in The Open Source Way.
  • Transparency
  • When we have access to the information and materials to do our best work, we can build on each other’s work.
  • Inclusivity
  • It’s not inclusivity Another principle is more closely related. Review the principles in The Open Source Way.
  • Meritocracy
  • It’s not meritocracy. Another principle is more closely related. Review the principles in The Open Source Way.
  • Release early and often. Another principle is more closely related. Review the principles in The Open Source Way.
  • It’s not release early and often.
Hint.
🔗
🔗
🔗
🔗
🔗

Subsection 2.2.2 FOSS Community Roles

One way of understanding FOSS communites is to consider the different roles that people take on in these communities. Some of these roles include Users, Requestors, Contributors, Maintainers and Leaders. These roles are prototypical and not every one of them roles will exist exactly in every FOSS community. Some communities will have slightly different roles, or multiple roles may be combined, etc. In addition, a given individual might simultaneously, or at different times take on multiple roles. So even though they are not exact or universal, understanding these prototypical roles can be helpful in understanding how work happens in FOSS communities.
🔗
If you would like you can review a discussion of these roles in the speaker notes in the slides for this chapter.
🔗

Exercises

1.
Consider each of the actions described below. For each action, select the role (or roles) of the individual(s) that would most likely be responsible for the action.
🔗
(a)
Choosing the license under which the project will be released.
🔗
  • Users
  • Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Requestors
  • It’s not requestors. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Contributors
  • It’s not contributors. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Maintainers
  • It’s not maintainers. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Leaders
  • Leaders determine how a project will be licensed.
Hint.
🔗
🔗
(b)
Using the software in a new, unanticipated or creative way.
🔗
  • Users
  • Users have the freedom to choose how to use software.
  • Requestors
  • It’s not requestors. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Contributors
  • It’s not contributors. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Maintainers
  • It’s not maintainers. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Leaders
  • It’s not leaders. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
Hint.
🔗
🔗
(c)
Asking that a useful new feature be added to the software.
🔗
  • Users
  • Users only use the software as is.
  • Requestors
  • Requestors request new features.
  • Contributors
  • It’s not contributors. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Maintainers
  • It’s not maintainers. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Leaders
  • It’s not leaders. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
Hint.
🔗
🔗
(d)
Discovering a bug in the software.
🔗
  • Users
  • Users detect bugs and report them.
  • Requestors
  • Requestors detect bugs and report them.
  • Contributors
  • It’s not contributors. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Maintainers
  • It’s not maintainers. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Leaders
  • It’s not leaders. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
Hint.
🔗
🔗
(e)
Providing a code patch that fixes a bug in the software.
🔗
  • Users
  • It’s not users. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Requestors
  • It’s not requestors. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Contributors
  • Contributors patch the code.
  • Maintainers
  • It’s not maintainers. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Leaders
  • It’s not leaders. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
Hint.
🔗
🔗
(f)
Submitting an improved set of installation instructions.
🔗
  • Users
  • It’s not users. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Requestors
  • It’s not requestors. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Contributors
  • Contributors contribute more than just code, such as installation instructions.
  • Maintainers
  • It’s not maintainers. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Leaders
  • It’s not leaders. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
Hint.
🔗
🔗
(g)
Documenting a bug in the issue tracker so others can fix it.
🔗
  • Users
  • It’s not users. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Requestors
  • Requestors can do bug documenting.
  • Contributors
  • Contributors contribute more than just code, such as bug documenting.
  • Maintainers
  • It’s not maintainers. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Leaders
  • It’s not leaders. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
Hint.
🔗
🔗
(h)
Defining the goals for the next year of work on the project.
🔗
  • Users
  • It’s not users. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Requestors
  • It’s not requestors. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Contributors
  • It’s not contributors. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Maintainers
  • It’s not maintainers. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Leaders
  • Leaders determine the goals for a project.
Hint.
🔗
🔗
(i)
Incorporating a contributed bug fix into the main branch.
🔗
  • Users
  • It’s not users. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Requestors
  • It’s not requestors. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Contributors
  • It’s not contributors Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Maintainers
  • Maintainers are responsible for the code, including accepting bug fixes.
  • Leaders
  • It’s not leaders. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
Hint.
🔗
🔗
(j)
Redesigning a software module in the system.
🔗
  • Users
  • It’s not users. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Requestors
  • It’s not requestors. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Contributors
  • Contributors contribute to design. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
  • Maintainers
  • Maintainers are responsible for the code, including designing.
  • Leaders
  • It’s not leaders. Another role (or roles) is most likely to be responsible for this activity. Review the roles in the chapter slides.
Hint.
🔗
🔗
🔗
🔗
🔗
You have attempted of activities on this page.
🔗
PrevTopNext