Domain review: community

The last domain review, on Thursday, April 22, covered the GitHub community, worth 5 to 10 in 100 of the exam. Malik Osei, who maintains open-trail-report, joined by video from his kitchen, because, as Priya put it, "he is the community". The outline lists six skills: the benefits of open source and GitHub Sponsors, how GitHub supports open source projects, following people and organizations, the GitHub Marketplace, inner source and open source principles inside organizations, and when to use forks, templates and discoverable repositories. Owen had ticks on almost all of them after MSBA-161's last two lessons, so the session became a fast round of scenario questions, with Malik answering from experience whenever Owen hesitated.

Why open source

Open source software is published under a license that lets anyone use, study, change and share it. The benefits come up in questions from both sides. For users and organizations: lower cost, the freedom to inspect and adapt code, no dependence on a single vendor, and security that benefits from many eyes. For contributors: learning, a public record of their work, and influence over tools they depend on. For maintainers and the projects: more contributors, faster bug reports and fixes, and a community that outlasts any one person. Tidewater's open-trail-report format exists because two other trail organizations wanted to publish reports the same way and were willing to help.

Open source still needs a license. Without one, as lesson 4 noted, the code is visible but all rights are reserved. Permissive licenses such as MIT and Apache 2.0 allow reuse with few conditions; copyleft licenses such as the GNU GPL require that changed versions are shared under the same license. GitHub detects the license file and shows a summary of what it permits, requires and forbids. Open-trail-report uses MIT for its code and a Creative Commons Attribution license for its data.

How GitHub supports open source

GitHub supports open source projects in several practical ways. Public repositories get unlimited collaborators and free GitHub Actions minutes on GitHub-hosted runners, free security features such as Dependabot alerts, secret scanning and code scanning, and free GitHub Pages. Community features help maintainers: community health files and the community profile checklist, issue and pull request templates, Discussions, labels such as good first issue that GitHub highlights for newcomers, interaction limits and moderation tools. GitHub Sponsors lets people and organizations fund the developers and projects they rely on, and GitHub also runs programs such as the GitHub Secure Open Source Fund and the GitHub Archive Program, which preserves open source code for the long term.

GitHub Sponsors

GitHub Sponsors lets a person or organization sponsor an open source developer or project with monthly or one-time payments. A maintainer with an approved Sponsors profile sets tiers, each with an amount and an optional description of what sponsors receive, such as a name in the README. A Sponsor button appears on repositories that list the maintainer in a FUNDING.yml file in the .github folder, which can also link to other funding platforms. GitHub does not take a fee on sponsorships from personal accounts; payment-processing costs may apply to sponsorships from organizations. The exam usually asks what Sponsors is for and which file adds the Sponsor button.

Following people and organizations

Following a user or organization on GitHub puts their public activity in your personal dashboard feed: new repositories, releases, stars and similar events. It does not give access, and it does not subscribe you to notifications, which come from watching and participating, as lesson 5 explained. People follow maintainers whose work they use, colleagues, and organizations whose projects they want to hear about. Your followers and the people you follow are shown on your profile. The distinction the exam tests is between following, watching and starring.

The GitHub Marketplace

The GitHub Marketplace, covered in MSBA-161 lesson 6, is GitHub's catalog of apps, which connect to GitHub and act on repositories, and actions, reusable workflow steps. Listings show the publisher, whether the publisher is verified, pricing, the permissions requested and the publisher's policies. The exam asks what the Marketplace is for, how an app differs from an action, and what to check before installing something: whether the permissions requested match the job, and who publishes it.

Inner source

Inner source applies open source practices inside an organization. Repositories are made visible to colleagues across teams, through internal visibility on Enterprise or a base permission of Read on other plans; projects have clear READMEs and contributing guides; anyone can propose a change by pull request; designated maintainers, often listed in CODEOWNERS, review and decide; and decisions happen in the open in issues and discussions. The benefits are less duplicated work, faster fixes from the people who need them, shared knowledge, and better documentation, because outsiders to a team need it. Tidewater's inner source moment, in MSBA-161 lesson 11, was an editor fixing a typo in the TrailCheck site's footer herself instead of filing a request with the web team.

Forks, templates and discoverable repositories

The last skill brings together choices from earlier lessons. Forks are for contributing to someone else's project or building a variant that stays connected to it. Templates are for starting new projects from a standard structure with a fresh history. Discoverability is about helping people find a repository: a clear description, topics such as hiking-trails or open-data, a good README, a license, a website link, and starring and sharing; GitHub's Explore pages and search use these signals. For inner source, discoverability inside the organization matters as much: a pinned repository on the organization profile and a profile README that lists the main projects help colleagues find what already exists.

Making a first contribution

Questions often follow a newcomer through a first contribution, so it helps to know the usual path. Find a project and an issue labeled good first issue or help wanted; read the README, CONTRIBUTING.md and CODE_OF_CONDUCT.md; comment on the issue to say you would like to work on it, so no one duplicates the effort; fork the repository, create a branch, make the change and push it to the fork; open a pull request to the original repository that follows its template and links the issue; and respond to review. Maintainers of busy projects often ask newcomers to discuss larger changes in an issue or discussion first, so that nobody spends a weekend on a change the project will not accept.

Profiles and public presence

A personal profile on GitHub shows pinned repositories, a contribution graph of activity over the past year, achievements, followers and an optional profile README, which appears when a repository has the same name as the account and contains a README. Organizations have a profile too, with pinned repositories and a README stored in the public .github repository, as Tidewater set up in MSBA-161 lesson 5. A clear profile makes a maintainer or project easier to trust and find, which is part of what the outline means by discoverable repositories. Contributions to private repositories can be shown on the graph as anonymous counts if the person chooses.

Moderation and healthy communities

Healthy communities need care as well as code. A code of conduct sets expectations, and maintainers enforce it with GitHub's moderation tools: hiding disruptive comments, locking heated conversations, setting temporary interaction limits that restrict who can comment on a public repository, reporting abuse to GitHub, and blocking users from an organization. Organization owners can give trusted people the moderator role to do this without full ownership. Malik uses interaction limits once a year, when a local news story sends a wave of new visitors to the project.

Malik's advice

At the end, Owen asked Malik what one thing he would want a GitHub Foundations candidate to understand about community. Malik said that most open source work is not code: it is answering questions, improving documentation, reviewing, triaging and welcoming people. "If an exam question asks how a non-developer can contribute to open source," he said, "every one of those is a right answer." Owen added that to his notes as the last line of the domain reviews.