You can create a Git repository to host your knowledge contributions anywhere (GitLab, Gerrit, etc.) but it may be favorable to create one on GitHub. The following instructions show you how to create a knowledge repository in GitHub and contribute to the taxonomy.
- You have a GitHub account
- You have a forked copy of the taxonomy repository
- Verify that the model does not already know the knowledge you want to submit
To create a new GitHub repository, follow the GitHub documentation in Creating a new repository.
The specific steps are listed as follows:
- In your GitHub profile page, navigate to the repositories tab. You will see a search bar where you can search your repositories, or create a new one.
- This takes you to a page titled “Create a new repository”. Create a custom name for your repository and add a README.md file. For example, “knowlege_contributions” could be a good name for your repository.
- Click “Create” when you are all set.
There are many online tools that can help you convert your documents to markdown. If you are using a wiki page for your contributions, you can use pandocs to convert the documents. For wikipedia sources on pandoc, use from: mediawiki
and convert to: markdown_strict
to access the proper markdown format.
To add a file to your GitHub repository, follow the GitHub documentation in Adding a file to a repository.
The specific steps are listed as follows:
-
Navigate to “Add files”. Click “Create new file” if you want to manually add your markdown content. Click “Upload files” if you have a file locally to add.
-
Add a description and commit your changes.
Since this is your own repository, you can commit directly to the
main
branch. -
You can then see your new content in your repository.
[!IMPORTANT] Make a note of your commit SHA; you need it for your
qna.yaml
.
Navigate to your forked taxonomy repository and ensure it is up-to-date.
There are a few ways you can create a pull request:
- For details on the local process, check out The GitHub Workflow Guide in the kubernetes documentation and the GitHub flow in the GitHub documentation.
- For details on contributing using the GitHub webpage UI, see Contributing using the GH UI or Creating a pull request in the GitHub documentation.
Here are a few things to check before seeking reviews for your contribution:
- Your
qna.yaml
follows the proper formatting. See examples in Knowledge: YAML examples - Ensure all parameters are set. Especially the
document
,repo
,commit
andpattern
keys; these parameters are specific to knowledge contributions and require more analysis. - Include an
attribution.txt
file for citing your sources. see For your attribution.txt file for more information.
The following table outlines the expected timing for the PR(s) you have put in. The PRs go through a few steps, and checks, but you should be able to map your label
to
the place that it is in.
Label | Actor | Action | Duration |
---|---|---|---|
Contributor | Submit PR | - | |
Contributor | Fix failed PR checks | - | |
triage-needed
|
Triager | Review PR, ask for changes | Days |
triage-requested-changes
|
Contributor | Make requested changes | Days |
precheck-generate-ready
|
Triager | Run prechecks and generate | Days |
community-build-ready
|
Backend | Model gets retrained | Weeks |
Triager | Check the numbers and PR merged or closed | - |