|
| 1 | +# Contributing to MarkLogic Workflow |
| 2 | + |
| 3 | +MarkLogic Workflow welcomes new contributors. This document will guide you |
| 4 | +through the process. |
| 5 | + |
| 6 | + - [Question or Problem?](#question) |
| 7 | + - [Issues and Bugs](#issue) |
| 8 | + - [Feature Requests](#feature) |
| 9 | + - [Submission Guidelines](#submit) |
| 10 | + |
| 11 | +## <a name="question"></a> Got a Question or Problem? |
| 12 | + |
| 13 | +If you have questions about how to use MarkLogic Workflow, please direct these to the |
| 14 | + |
| 15 | + |
| 16 | +## <a name="issue"></a> Found an Issue? |
| 17 | +If you find a bug in the source code or a mistake in the documentation, you can help us by |
| 18 | +submitting an issue to our [GitHub Issue Tracker][issue tracker]. Even better you can submit a Pull Request |
| 19 | +with a fix for the issue you filed. |
| 20 | + |
| 21 | +## <a name="feature"></a> Want a Feature? |
| 22 | +You can request a new feature by submitting an issue to our [GitHub Issue Tracker][issue tracker]. If you |
| 23 | +would like to implement a new feature then first create a new issue and discuss it with one of our |
| 24 | +project maintainers. |
| 25 | + |
| 26 | +## <a name="submit"></a> Submission Guidelines |
| 27 | + |
| 28 | +### Submitting an Issue |
| 29 | +Before you submit your issue search the archive, maybe your question was already answered. |
| 30 | + |
| 31 | +If your issue appears to be a bug, and hasn't been reported, open a new issue. |
| 32 | +Help us to maximize the effort we can spend fixing issues and adding new |
| 33 | +features, by not reporting duplicate issues. Providing the following information will increase the |
| 34 | +chances of your issue being dealt with quickly: |
| 35 | + |
| 36 | +* **Overview of the Issue** - if an error is being thrown a stack trace helps |
| 37 | +* **Motivation for or Use Case** - explain why this is a bug for you |
| 38 | +* **MarkLogic Workflow Version** - is it a named version or from our dev branch |
| 39 | +* **Operating System** - Mac, windows? details help |
| 40 | +* **Suggest a Fix** - if you can't fix the bug yourself, perhaps you can point to what might be |
| 41 | + causing the problem (line of code or commit) |
| 42 | + |
| 43 | +### Submitting a Pull Request |
| 44 | + |
| 45 | +#### Fork MarkLogic Workflow |
| 46 | + |
| 47 | +Fork the project [on GitHub](https://github.com/adamfowleruk/marklogicworkflow/fork) and clone |
| 48 | +your copy. |
| 49 | + |
| 50 | +```sh |
| 51 | +$ git clone [email protected]:adamfowleruk/marklogicworkflow.git |
| 52 | +$ cd marklogicworkflow |
| 53 | +$ git remote add upstream git://github.com/adamfowleruk/marklogicworkflow.git |
| 54 | +``` |
| 55 | + |
| 56 | +All bug fixes and new features go into the dev branch. |
| 57 | + |
| 58 | +We ask that you open an issue in the [issue tracker][] and get agreement from |
| 59 | +at least one of the project maintainers before you start coding. |
| 60 | + |
| 61 | +Nothing is more frustrating than seeing your hard work go to waste because |
| 62 | +your vision does not align with that of a project maintainer. |
| 63 | + |
| 64 | + |
| 65 | +#### Create a branch for your changes |
| 66 | + |
| 67 | +Okay, so you have decided to fix something. Create a feature branch |
| 68 | +and start hacking: |
| 69 | + |
| 70 | +```sh |
| 71 | +$ git checkout -b my-feature-branch -t origin/dev |
| 72 | +``` |
| 73 | + |
| 74 | +We recommend you use the [GitFlow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) method to create and maintain branches. |
| 75 | + |
| 76 | +#### Formatting code |
| 77 | + |
| 78 | +We use [.editorconfig][] to configure our editors for proper code formatting. If you don't |
| 79 | +use a tool that supports editorconfig be sure to configure your editor to use the settings |
| 80 | +equivalent to our .editorconfig file. |
| 81 | + |
| 82 | +#### Commit your changes |
| 83 | + |
| 84 | +Make sure git knows your name and email address: |
| 85 | + |
| 86 | +```sh |
| 87 | +$ git config --global user.name "J. Random User" |
| 88 | +$ git config --global user.email "[email protected]" |
| 89 | +``` |
| 90 | + |
| 91 | +Writing good commit logs is important. A commit log should describe what |
| 92 | +changed and why. Follow these guidelines when writing one: |
| 93 | + |
| 94 | +1. The first line should be 50 characters or less and contain a short |
| 95 | + description of the change including the Issue number prefixed by a hash (#). |
| 96 | +2. Keep the second line blank. |
| 97 | +3. Wrap all other lines at 72 columns. |
| 98 | + |
| 99 | +A good commit log looks like this: |
| 100 | + |
| 101 | +``` |
| 102 | +Fixing Issue #123: make the whatchamajigger work in MarkLogic 8 |
| 103 | +
|
| 104 | +Body of commit message is a few lines of text, explaining things |
| 105 | +in more detail, possibly giving some background about the issue |
| 106 | +being fixed, etc etc. |
| 107 | +
|
| 108 | +The body of the commit message can be several paragraphs, and |
| 109 | +please do proper word-wrap and keep columns shorter than about |
| 110 | +72 characters or so. That way `git log` will show things |
| 111 | +nicely even when it is indented. |
| 112 | +``` |
| 113 | + |
| 114 | +The header line should be meaningful; it is what other people see when they |
| 115 | +run `git shortlog` or `git log --oneline`. |
| 116 | + |
| 117 | +#### Rebase your repo |
| 118 | + |
| 119 | +Use `git rebase` (not `git merge`) to sync your work from time to time. |
| 120 | + |
| 121 | +```sh |
| 122 | +$ git fetch upstream |
| 123 | +$ git rebase upstream/dev |
| 124 | +``` |
| 125 | + |
| 126 | + |
| 127 | +#### Test your code |
| 128 | + |
| 129 | +We are working hard to improve MarkLogic Workflow's testing. If you add new actions |
| 130 | +in process models then please write unit tests in the shtests directory. |
| 131 | +When finished, verify that the self-test works. |
| 132 | + |
| 133 | +```sh |
| 134 | +$ cd shtests |
| 135 | +$ ./all.sh |
| 136 | +``` |
| 137 | + |
| 138 | +Make sure that all tests pass. Please, do not submit patches that fail. |
| 139 | + |
| 140 | +#### Push your changes |
| 141 | + |
| 142 | +```sh |
| 143 | +$ git push origin my-feature-branch |
| 144 | +``` |
| 145 | + |
| 146 | +#### Submit the pull request |
| 147 | + |
| 148 | +Go to https://github.com/adamfowleruk/marklogicworkflow and select your feature branch. Click |
| 149 | +the 'Pull Request' button and fill out the form. |
| 150 | + |
| 151 | +Pull requests are usually reviewed within a few days. If you get comments |
| 152 | +that need to be to addressed, apply your changes in a separate commit and push that to your |
| 153 | +feature branch. Post a comment in the pull request afterwards; GitHub does |
| 154 | +not send out notifications when you add commits to existing pull requests. |
| 155 | + |
| 156 | +That's it! Thank you for your contribution! |
| 157 | + |
| 158 | + |
| 159 | +#### After your pull request is merged |
| 160 | + |
| 161 | +After your pull request is merged, you can safely delete your branch and pull the changes |
| 162 | +from the main (upstream) repository: |
| 163 | + |
| 164 | +* Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows: |
| 165 | + |
| 166 | + ```shell |
| 167 | + git push origin --delete my-feature-branch |
| 168 | + ``` |
| 169 | + |
| 170 | +* Check out the dev branch: |
| 171 | + |
| 172 | + ```shell |
| 173 | + git checkout dev -f |
| 174 | + ``` |
| 175 | + |
| 176 | +* Delete the local branch: |
| 177 | + |
| 178 | + ```shell |
| 179 | + git branch -D my-feature-branch |
| 180 | + ``` |
| 181 | + |
| 182 | +* Update your dev with the latest upstream version: |
| 183 | + |
| 184 | + ```shell |
| 185 | + git pull --ff upstream dev |
| 186 | + ``` |
| 187 | + |
| 188 | +[issue tracker]: https://github.com/adamfowleruk/marklogicworkflow/issues |
| 189 | +[.editorconfig]: http://editorconfig.org/ |
0 commit comments