Access Request

How to get access to the BodhiTree repositories once your feature request has been approved.

Access is granted after approval, not before. See Feature Request Process. Until you are added to the organization the repository is not visible to you, and a clone will fail with a repository not found error rather than a permission error.

What you are asking for

You need

Why

Membership of the bodhitree-iitb GitHub organization

To see the repository, open issues and raise pull requests

Push access to the platform repository

To push feature/* and bugfix/* branches

An SSH key registered on your GitHub account

The clone instructions in Platform Setup & Installation use SSH

You do not get push access to main or dev; both are protected and take changes only through pull requests. See Branching Style.

Steps

  1. Confirm your feature request is approved.
    Approval is given by the team listed in Feature Request Process.

  2. Create a GitHub account if you do not already have one, and add an SSH key to it. Use an account you will keep; commits are attributed to it permanently.

  3. Message the Core Dev Team on Microsoft Teams with:

    • your GitHub username,

    • your name and institute e-mail address,

    • the feature request or issue you have been approved for,

    • how long you expect to need access.

  4. Wait for the invitation. GitHub e-mails you an invitation to join the bodhitree-iitb organization. Accept it; an unaccepted invitation expires and the request has to be made again.

  5. Verify your access:

    git clone git@github.com:bodhitree-iitb/Bodhitree.git
cd Bodhitree
git checkout dev

    If the clone succeeds and git checkout dev works, you are set up. Continue with Platform Setup & Installation.

  6. Follow up if you have not heard back within a few days, the same advice as for the feature request itself.

While you have access

  • Push only to your own feature/* or bugfix/* branches.

  • Never commit credentials, tokens or .env files. The repository ships *.sample files for this reason; keep your real configuration untracked.

  • Tell the Core Dev Team when you no longer need access so it can be revoked.

To be confirmed

The following details could not be verified from the repository and should be filled in by the Core Dev Team:

  • Who grants access: the specific person or role on the Core Dev Team, and the exact Microsoft Teams channel to message.

  • Whether an access request form exists (as it does for feature requests) or whether a Teams message is the whole process.

  • Whether access to anything beyond GitHub is needed, for example the staging server, the Jenkins instance, or the Docker registry.

  • The expiry policy, if any, for contributor access.