First of all, you are welcome to email the Documentation Listserv (email@example.com) with problems you find in the documentation. However, we welcome you to participate in the process of improving things. Below are various ways you can contribute your time and skills.
Note: Changes to the official repository are processed into HTML, PDF and ePub nightly at 11pm. (see http://docs.evergreen-ils.org/)
Note: The documentation is now hosted in the main Evergreen git repository:
filename.adoc. This will display the HTML version of your file. Then you can proofread your document and look for anything strange.
This workflow is primarily for the few DIG members with permission to push to the master repository. If you do not have permission yet, you can start the request process by contacting the Git Admins group firstname.lastname@example.org. You can also push to another public repository, such as the Evergreen working repository or another host such as GitHub. Then email the DIG email list email@example.com with the location of your repository so they can pull your changes into master.
Use these procedures on Linux, Mac OS X, or GitBash on Windows.
git clone git://git.evergreen-ils.org/Evergreen.gitto create an initial copy of the repository on your machine. This will clone the whole Evergreen repository, which contains the docs directory where all the documentation lives.
cd Evergreen/docs- Moves to the new directory you just cloned.
If you aren't able to push to the documentation folder, try these troubleshooting steps:
firstname.lastname@example.org:Evergreen.git. Specifically, make sure that:
gitis followed by the
:, not a
git fetch –all
git checkout master
git pull- Pulls the most recent changes into your cloned version. This avoids merging issues and errors when "pushing" your changes to the remote repository.
After you've made your changes, make sure that your documentation is included in the appropriate manual(s). To do this, make sure that there is a
include::path/to/documentation.adoc statement in the appropriate
root_*.adoc file (e.g.
root_circulation.adoc for the circulation manual).
Then test to make sure that the docs build correctly. The following examples use the Circulation manual, but you will want the filename
root_circulation.adoc to match the manual you are trying to test.
asciidoc root_circulation.adoc- Converts AsciiDoc text files to HTML format. This will give you errors if the AsciiDoc format is incorrect. Once it succeeds, verify that the HTML appears as you expect. Finally, delete the output files (e.g.
rm *.html) to prevent them from being committed along with your AsciiDoc files.
a2x –fop root_circulation.adoc- Converts AsciiDoc text files to PDF format. Verify that the PDF appears as you expect. Finally, delete the output files (e.g.
rm *.pdf) to prevent them from being committed along with your AsciiDoc files.
a2x -f=epub root_circulation.adoc- Converts AsciiDoc text files to ePub format. Once it succeeds, delete the output files (e.g.
rm *.epub) to prevent them from being committed along with your AsciiDoc files.
When you are satisfied with your changes, commit the files.
git add- Tells git that you have added or edited files on your local machine and want to add them into the repository. The changes are not committed yet.
git status- Check to make sure that you are committing the correct files.
git commit -sOR
git commit -sm "Docs: [what you changed]"- Commits changes to the repository. You must provide a note on what you changed, beginning with the phrase "Docs: ". If you use the shorter form, a text editor will open (usually vim) where you will write your change note. (Using the -m switch is a time-saver if your note is short) To commit all changes, use
git commit ..
git log -3- Shows the 3 most recent commits. Check to make sure that your commit:
After you have committed to master
git checkout [BRANCH]- you will probably also want to add your change to the documentation for all relevant versions. For example, if you are documenting a feature that was added to version 3.2, you will want to add it to the 3.2 documentation. Release branches are in the form
rel_3_2, so for our example, you would type
git checkout rel_3_2.
git pull- if this branch has changed since the last time you ran this command.
git cherry-pick [NUMBER OF COMMIT]- if you didn't note the number of the commit, run
git checkout master; git log -3to find it. Then be sure to return to this branch with
git checkout [BRANCH].
If you are committing a change that somebody else made:
git commit -s –author="Firstname Lastname email@example.com"
These procedures are recommended if you are not comfortable with the command line.
git://git.evergreen-ils.org/Evergreen.git; leave "Target" blank to use the default path, or enter something else (it creates a new directory, so don't use one that exists already). Click Clone.
filename.adoc. Then you can proofread your document and look for anything strange.
Unstaged Changes(red). Click a file to see color-coded changes in the pane to the right.