If you’re new to GitHub and open source in general, figuring out how to get set up can be a challenge. You may want to read through the GitHub Help pages on Setting up and managing your GitHub profile.
You do not need a separate work account and personal account. Instead, you can link multiple email addresses to the same GitHub account, which is almost always preferred.
Lawrence Livermore National Laboratory, @LLNL.
Membership in the @LLNL GitHub organization will soon require that 2FA has been enabled on your GitHub account. There are several options for configuring 2FA for your GitHub account:
Additional 2FA info:
Send an email, with your GitHub username included, to the LLNL GitHub admins from your
@llnl.gov email, requesting to be added to the organization.
After an administrator has added you to the organization, you will receive a notification email from GitHub. Alternatively, once the invitation has been sent, you will see a notification banner at the top of github.com/llnl which you can use to accept the invitation.
Head over to the @LLNL People page and make your membership
Before content is placed into an LLNL GitHub.com repository, it should be reviewed and released via LLNL’s Information Management (IM) process. All information produced by LLNL must follow the guidance set forth by the LLNL IM policy for both initial release and incremental contributions .
Remember that these repositories are hosted on GitHub servers, NOT LLNL servers, and content placed in them should be limited to “email like” communications. That means:
When in doubt, contact a Derivative Classifier (DC) and/or IM for further guidance.
Make sure your repo contains:
An appropriate open source license and
LLNL-CODE-xxxxxx release number. See the LLNL Software Licensing page for details and examples.
A README file that summarizes what the software does and how others can use it.
A NOTICE file that includes LLNL auspice and disclaimer statements.
After your project has been initially released on GitHub and you are ready to provide a new version, a good practice is to tag the version and include release notes.
Another good practice is to provide user documentation. Read the Docs (RtD) is a common platform for user guides, tutorials, quick start instructions, and other forms of documentation. Our .github repo contains step-by-step instructions for setting up a RtD instance, a template you can start with, and links to various resources for tips and additional details.
Submit your repo to DOE CODE so others can find it when searching through DOE-funded projects. After your repo is included in DOE CODE, you may also want to add the digital object identifier (DOI) to the repo. See the relevant section of our LLNL Software Licensing page for more information.
Repositories within the LLNL organization are owned and managed by LLNL. Please do not create personal repositories here.
Make sure your repository is included on this website’s home page and full catalog. If you’ve set up your repository within the LLNL organization, you don’t need to take any action; it will automatically appear after the next data update.
If your repository exists under a different organization, you can move it to LLNL by selecting “Transfer Ownership” under Settings.
Alternatively, you can submit a pull request updating the
input_lists.json file, with your organization and/or repository names.
If you have a project logo, please follow the instructions for naming and uploading the file. If your repo is part of a non-LLNL organization that has its own avatar, that image will automatically display next to the repo name in the catalog, unless superseded by a repo-specific logo.
Now that your project is on GitHub, make sure users and contributors can find it! There are several ways to do this. Contact email@example.com if you need help.
Include meaningful metadata (description and topic tags) in your repository. Example: Spack lists several topic tags below a one-sentence description.
Start with our list of recommended, standardized topics.
See helpful hints on GitHub’s topic help page. Add tags relevant to your project’s programming language, platforms, and more (e.g., Python, HPC, Linux).
Publicize any outreach activities or major milestones related to your project. Examples: You have a paper/poster/presentation accepted at a conference; you’re hosting a workshop or webinar; your project is nominated for an award; or you’re speaking on a podcast or guest blogging.
Submit a pull request! This website is a GitHub repo just like any other LLNL open source project. News is housed in the
_posts directory, and templates are found in the LLNL/.github repo. See the guidelines below about contributing.
Before contributing, please contact firstname.lastname@example.org with your idea or if you have questions about whether your proposed content requires the LLNL review and release process.
Remove your repo’s topic tags (e.g.,
math-physics), which connect it to this website’s browsable categories. Also remove the
radiuss tag, if applicable.
Submit a pull request updating the
input_lists.json file to remove your repo’s name.
Change your repo’s status via Settings > Manage Access > Who has access > Manage > Danger Zone > Archive this repository (
settings#danger-zone). Contact email@example.com if for some reason GitHub won’t let you complete this step.
The process to transfer organizational ownership is straightforward, but generally discouraged. This should really only be done for projects that are starting to build a “bigger than LLNL” community, and the decision should not be made lightly.
Migrating the repo outside of the LLNL organization requires an organization admin. Contact firstname.lastname@example.org to coordinate the move.
Once the repository has moved to the new organization:
Submit a pull request updating the
input_lists.json file to add the new organization/repo’s name. This allows for the software catalog to continue including the project even after it moves.
Retain topic tags (e.g.,
math-physics) to connect it to this website’s browsable categories, including the
radiuss tag, if applicable.
Refer to individual projects for their requirements on accepting contributions. In general though, we follow the “fork and pull” Git workflow model:
Fork a repository.
Develop your changes in your fork.
Sync your fork to the upstream repository (
git remote add upstream email@example.com:org/repo.git).
Create a pull request to the “upstream” repository.
If approved, changes will be merged in by a repository maintainer.