These FAQs primarily target LLNL developers working in the LLNL GitHub organization. Don’t see your question listed below? Please contact LLNL GitHub admins.
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.
Update your profile information.
Lawrence Livermore National Laboratory, @LLNL.
@LLNL email address (and any aliases) to your Email Settings page. This will link any commits done via your Git identity to your GitHub account.
Membership in the @LLNL GitHub organization requires that 2FA has been enabled on your GitHub account. There are several options for configuring 2FA for your GitHub account:
Additional 2FA info:
If you are an employee at LLNL and have 2FA enabled, you are eligible to join the LLNL GitHub organization and appear in the member list.
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 community health files:
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.
A CODE OF CONDUCT file that defines standards for how to engage in your project’s community.
A CONTRIBUTING file that communicates how others should contribute to your repo.
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 LLNL/.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.
If your repo is research software, consider submitting it to the Journal of Open Source Software (JOSS). Submission will produce a citation to include in your README file, then users or other researchers can cite your software correctly. The JOSS RtD site describes the submission requirements. JOSS defines research software as “software that solves complex modeling problems in a scientific context (physics, mathematics, biology, medicine, social science, neuroscience, engineering); supports the functioning of research instruments or the execution of research experiments; extracts knowledge from large data sets; offers a mathematical library; or similar.” (You can also become a reviewer, if you are so inclined.)
Repositories within the LLNL organization are owned and managed by LLNL. Please do not create personal repositories here.
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. List your organization under the
"orgs" line only if you intend for all of its repositories to be included in the catalog (e.g.,
glvis); otherwise, list only the repository under the
"repos" line within the context of your organization (e.g.,
If your repo is part of the RADIUSS project, be sure to add it to that repo’s
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).
Let Twitter followers know your project is available on GitHub. Feel free to tag this handle on your own tweet, or submit a request to firstname.lastname@example.org so we can tweet on your behalf.
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.
Include a summary of your project with GitHub and documentation links on LLNL’s Computing website. Contact email@example.com for this particular task.
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 the specific topic tags (e.g.,
math-physics) that connect it to this website’s browsable categories.
Remove the repo from the RADIUSS
contributor-ci.yaml file, 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.
Update the org in the RADIUSS
contributor-ci.yaml file, 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.