fossasia/member: GitHub organization onboarding and access workflow

Why fossasia/member exists

The repository addresses a specific coordination problem: FOSSASIA accepts contributions without requiring organization membership, but membership makes participation in its public projects easier. According to the README, joining the organization enables GitHub features such as assigning issues to contributors and adding members to project teams. It also places new members in the Codeheat team for possible participation in future contests.

This makes fossasia/member relevant to community developers who want a visible connection with FOSSASIA, not to engineers looking for a library, command-line application or developer framework. The repository does not attempt to decide who should contribute to a particular codebase. It handles enrollment into the GitHub organization and communicates the state of that process.

The distinction matters because public contribution and organization access are separate states. The README explicitly says that anyone can contribute to FOSSASIA public projects. An organization membership is therefore useful for collaboration and profile visibility, but it is not a general contribution prerequisite. The onboarding request is also not an invitation itself. GitHub must send an organization invitation after the request is processed, and the applicant must accept it before membership can be made public.

From join-fossasia.md issue to GitHub invitation

The documented flow starts with a GitHub issue opened through the `join-fossasia.md` template. The applicant adds a short introduction and explains why they want to join FOSSASIA. When the issue is submitted, GitHub automatically applies the `org-invite` label. That label appears to be the handoff between the public request form and automated processing.

A GitHub Action then processes the labeled onboarding issue. The README says processing normally takes a few seconds. After processing, the applicant receives a comment containing two pieces of information: FOSSASIA organization membership status and Codeheat team membership status. The Action also closes the onboarding issue automatically.

The statuses distinguish several cases. An active organization status means the applicant is already a member. A pending organization invitation means GitHub has issued an invitation that still needs to be accepted. A pending Codeheat team status resolves after the organization invitation is accepted, while a failed team status requires manual intervention by a maintainer. This is a narrow state machine built around GitHub issue labels, automated comments, invitation state and issue closure.

The repository layout includes a `.github/` directory, which is consistent with an issue template and GitHub-hosted automation. However, the README does not name the workflow file, describe its triggers or permissions, or explain how it calls GitHub's API. The visible contract is therefore the issue and its status comment, not a documented package API.

Accepting the invitation and publishing membership

A processed request is not necessarily a completed membership. If the issue comment reports that the organization invitation is pending, the applicant must check GitHub notifications or email, open the invitation from FOSSASIA and accept it. The README states that acceptance must occur before organization membership can be made public.

After acceptance, the applicant changes the membership visibility in GitHub. The documented interface path starts from the profile picture in the upper-right corner, opens `Organizations`, selects `FOSSASIA`, opens `People`, locates the GitHub username and changes visibility from `Private` to `Public`. The repository also links directly to the FOSSASIA members page, where the same visibility setting can be changed.

This step is operationally significant. A user can therefore reach an active organization membership while the membership remains hidden from the public profile. Completion under the repository's definition includes both acceptance and public visibility. Once public, the FOSSASIA organization appears on the GitHub profile and the onboarding issue has already been closed by automation.

GitHub account security is outside this repository's control. The documentation does not describe identity verification beyond the invitation flow, and it does not promise a particular approval standard for the introductory issue. The issue asks for motivation, but the README does not enumerate review criteria. That is useful context for prospective members: the available public process is automated after submission, while the reasons for participation remain part of the request.

A first onboarding run through GitHub

There is no installation step for fossasia/member because it is operated through GitHub rather than installed as software. The repository says to open its onboarding form directly. A first-time contributor should use the Join FOSSASIA issue link, select the `join-fossasia.md` template, write a short introduction, explain the interest in FOSSASIA and submit the issue.

After submission, the applicant should verify that the issue has received the `org-invite` label. If it has, the documented expectation is a status comment after a few seconds and automatic issue closure. The next action depends on the comment. An active organization status leads to the visibility step. A pending organization invitation requires acceptance through GitHub notifications, email or the invitation page. A failed Codeheat status does not necessarily prevent organization membership, because the README says a maintainer must add the team membership manually.

The last documented step is optional discovery rather than enrollment. The README directs members to follow the FOSSASIA organization and use the `fossasia/star-me` repository to follow its instructions. It presents starring repositories and following the organization as ways to surface project updates in a personalized GitHub feed. The repository does not provide commands for StarMe and does not make running that script a requirement for completing membership.

Automation limits and manual recovery paths

The README presents normal processing as taking a few seconds, but it also acknowledges that onboarding can stall. An applicant who receives no response within a few minutes is told to check whether the organization invitation was accepted, inspect GitHub notifications and email, verify that the username appears on the FOSSASIA members page, and comment on the onboarding issue to request assistance.

The failed Codeheat team state is the clearest documented failure mode. Organization membership may proceed while team membership requires a maintainer to add the applicant manually. The workflow does not claim that every request completes without human intervention.

There are also missing implementation details that matter when judging the workflow. The README does not document retry behavior, duplicate submissions, rate-limit handling, invalid usernames, invitation expiration, or what happens if the Action cannot close the issue. It also does not explain whether an applicant can reopen a completed request or use an existing FOSSASIA issue to repair failed team access. Those cases require reading the workflow and issue-template files or asking a maintainer through the documented issue-comment path.

For automation engineers, the absent configuration surface is substantial. No environment variables, permissions matrix or reusable inputs are documented. The repository should not be treated as a generic organization-membership bot on the basis of this README alone.

GPL-2.0 and mixed repository contents

The repository identifies `GPL-2.0` as its license. The documentation does not explain which files or historical materials the license is intended to cover, so its practical effect cannot be determined from the README alone. Code copied from this repository would require reviewing the applicable `LICENSE` and the scope of any copied material. This is a licensing boundary, not legal advice.

The top-level structure contains `.github/`, `LICENSE`, `README.md` and `projects/`. The README says the repository also holds materials from past FOSSASIA community activities and contests, including an MBDyn tasks archive. That mixed content means the repository is not only a current onboarding document. Contributors browsing it for previous tasks or contribution history will encounter archival material alongside the membership workflow.

The repository has no GitHub releases, so the README provides no versioned distribution channel or upgrade notes for the onboarding system. Its last push was on 2026-09-05, which is recent relative to the repository status, but recency alone does not confirm compatibility with future GitHub workflow changes. The absence of releases also means adopters should inspect the current `.github/` configuration rather than looking for a stable release artifact.

How fossasia/member differs from manual organization onboarding

The direct alternative is manual onboarding through GitHub organization administration. A maintainer can invite a person, manage team membership manually and communicate status outside the repository. That approach avoids dependence on the repository's issue label and GitHub Action, but it places the request tracking and status communication in the maintainers' workflow.

fossasia/member instead uses a public GitHub issue as the intake record. The `join-fossasia.md` template collects the applicant's introduction, `org-invite` marks the request for automation, a GitHub Action writes the organization and Codeheat statuses, and the issue closes after processing. This creates a visible audit trail and a defined recovery point because the README instructs unsuccessful applicants to comment on the same issue.

The trade-off is equally concrete. The automated path is tied to GitHub and FOSSASIA's specific teams, labels and permission model. It does not expose a documented general-purpose onboarding mechanism for another organization. Manual administration may offer more case-by-case control, while this repository offers a repeatable public path at the cost of relying on undocumented automation internals.

Editorial conclusion

Contributors who want visible FOSSASIA organization membership should use this repository because it documents the complete issue, invitation, visibility, and troubleshooting path. Organizations seeking a configurable onboarding tool should not treat it as one, since the README does not expose the Action implementation, configuration options, or reusable API. Before adoption, verify the issue template, current `org-invite` label behavior, and the permissions required by the GitHub Action.

Frequently asked questions

Official sources

1. fossasia/member on GitHub
2. Issues
3. License: GPL-2.0
4. README