Have something you'd like to contribute to the framework? We welcome pull requests but ask that you carefully read this document first to understand how best to submit them; what kind of changes are likely to be accepted; and what to expect from the OpenHub Framework team when evaluating your submission.
...
Take Your First StepsUnderstand the basicsNot sure what a pull request is, or how to submit one? Take a look at GitHub's excellent
help documentation first.
Search Stack Overflow first; discuss if necessaryIf you're unsure why something isn't working or wondering if there is a better way of doing it please check on Stack Overflow first and if necessary start a discussion. This is the official
OpenHub Framework tag. In short the issue tracker should be used to report issues and make feature requests.
Search JIRA; create an issue if necessaryIs there already an issue that addresses your concern? Do a bit of searching in our
JIRA issue tracker to see if you can find something similar. If you do not find something similar, please create a new JIRA issue before submitting a pull request unless the change is truly trivial -- for example: typo fixes, removing compiler warnings, etc.
Create a BranchBranch from develop
Develop currently represents work toward OpenHub Framework baseline. Direct commit to public branches is not allowed. Please submit all pull requests there, even bug fixes and minor improvements. Backports to previous version will be considered on a case-by-case basis.
Use short branch namesBranches used when submitting pull requests should preferably be named according to JIRA issues, e.g. 'feature/OHFJIRA-5
'. Otherwise, use succinct, lower-case, dash (-) delimited names, such as 'fix-warnings', 'fix-typo', etc. In
fork-and-edit cases, the GitHub default 'patch-1' is fine as well. This is important, because branch names show up in the merge commits that result from accepting pull requests and should be as expressive and concise as possible.
Use OpenHub Framework Code StyleThe complete
OpenHub Framework Code Style reference is available on the wiki, but here's a quick summary:
Mind the whitespacePlease carefully follow the whitespace and formatting conventions already present in the framework.
- Spaces, not tabs. Tab should be converted to spaces.
- Unix (LF), not DOS (CRLF) line endings
- Eliminate all trailing whitespace
- Wrap Javadoc at 120 characters
- Aim to wrap code at 120 characters, but favor readability over wrapping
- Maximum size of one class should not exceed 700 lines.
- Preserve existing formatting; i.e. do not reformat code for its own sake
- Search the codebase using
git grep
and other tools to discover common naming conventions, etc. - UTF-8 encoding for Java sources
Add Apache license header to all new classes/*
* Copyright 2002-2016 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package ...;
Update Apache license header in modified files as necessaryAlways check the date range in the license header. For example, if you've modified a file in 2015 whose header still reads:
/*
* Copyright 2002-2011 the original author or authors.
Then be sure to update it to 2016 accordingly:
/*
* Copyright 2002-2016 the original author or authors.
Use @since tags for newly-added public API types and methodsFor example:
/**
* ...
*
* @author First Last
* @since 1.1
* @see ...
*/
Prepare Your CommitSubmit JUnit test cases for all behavior changesSearch the codebase to find related tests and add additional @Test
methods as appropriate. It is also acceptable to submit test cases on a per JIRA issue basis, for example:
package org.openhubframework.openhub.test;
/**
* Unit tests for OHF-123.
*
* @author FirstName LastName
*/
public class Ohf123Tests {
@Test
public void cornerOhf123() {
// ...
}
}
Squash commitsUse git rebase --interactive --autosquash
, git add --patch
, and other tools to "squash" multiple commits into a single atomic commit. In addition to the man pages for git, there are many resources online to help you understand how these tools work. The
Rewriting History section of Pro Git provides a good overview.
Use real name in git commitsPlease configure git to use your real first and last name for any commits you intend to submit as pull requests. For example, this is not acceptable:
Author: Nickname <user@mail.com>
Rather, please include your first and last name, properly capitalized:
Author: First Last <user@mail.com>
This helps ensure traceability and also goes a long way to ensuring useful output from tools like git shortlog
and others.
You can configure this via the account admin area in GitHub (useful for fork-and-edit cases); globally on your machine with
git config --global user.name "First Last"
git config --global user.email user@mail.com
or locally for the openhub-framework
repository only by omitting the '--global' flag:
cd openhub-framework
git config user.name "First Last"
git config user.email user@mail.com
Format commit messagesPlease read and follow the
Commit Guidelines section of Pro Git.
Most importantly, please format your commit messages in the following way (adapted from the commit template in the link above):
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here
Issue: OHFJIRA-1, OHFJIRA-2
- Use imperative statements in the subject line, e.g. "Fix broken Javadoc link".
- Begin the subject line with a capitalized verb, e.g. "Add, Prune, Fix, Introduce, Avoid, etc."
- Do not end the subject line with a period.
- Restrict the subject line to 50 characters or less if possible.
- Wrap lines in the body at 72 characters or less.
- Mention associated JIRA issue(s) at the end of the commit comment, prefixed with "Issue: " as above.
- In the body of the commit message, explain how things worked before this commit, what has changed, and how things work now.
Examples of commit messages:
Code Blocklanguage xml title #1
Clarification of contributing README
Added page to describe rules and principles how to contribute (https://openhubframework.atlassian.net/wiki/display/OHF/Rules+and+principles).
We strongly recommend discussing any serious submissions with the OpenHub Framework team prior to engaging in serious development work.
Issue: OHFJIRA-4
Code Block language xml title #2
Laying the foundation stone of redesigned admin GUI
Created new maven module ‘admin-console-client’ as module that holds all web resources of OpenHub admin console.
A build is realised with frontend-plugin. Only basic structure is created under src/main/resources/META-INF/resources/.
Location of resources is created with regard to scalability and customisation of build.
- source root dir for web resources is src/main/resources/META-INF/resources/
Issue: OHFJIRA-4
Run the Final ChecklistRun all tests prior to submissionSee the
building from source section for instructions. Make sure that all tests pass prior to submitting your pull request.
Submit your pull requestSubject line:
Follow the same conventions for pull request subject lines as mentioned above for commit message subject lines.
In the body:
- Explain your use case. What led you to submit this change? Why were existing mechanisms in the framework insufficient? Make a case that this is a general-purpose problem and that yours is a general-purpose solution, etc.
- Add any additional information and ask questions; start a conversation or continue one from JIRA.
- Mention the JIRA issue ID.
Note that for pull requests containing a single commit, GitHub will default the subject line and body of the pull request to match the subject line and body of the commit message. This is fine, but please also include the items above in the body of the request.
Mention your pull request on the associated JIRA issueAdd a comment to the associated JIRA issue(s) linking to your new pull request.
Expect discussion and reworkThe OpenHub team takes a very conservative approach to accepting contributions to the framework. This is to keep code quality and stability as high as possible, and to keep complexity at a minimum. Your changes, if accepted, may be heavily modified prior to merging. You will retain "Author:" attribution for your Git commits granted that the bulk of your changes remain intact. You may be asked to rework the submission for style (as explained above) and/or substance. Again, we strongly recommend discussing any serious submissions with the OpenHub Framework team prior to engaging in serious development work.
Note that you can always force push (git push -f
) reworked / rebased commits against the branch used to submit your pull request. In other words, you do not need to issue a new pull request when asked to make changes.
Not sure what a pull request is, or how to submit one? Take a look at GitHub's excellent
help documentation first.If you're unsure why something isn't working or wondering if there is a better way of doing it please check on Stack Overflow first and if necessary start a discussion. This is the official
OpenHub Framework tag. In short the issue tracker should be used to report issues and make feature requests.Is there already an issue that addresses your concern? Do a bit of searching in our
JIRA issue tracker to see if you can find something similar. If you do not find something similar, please create a new JIRA issue before submitting a pull request unless the change is truly trivial -- for example: typo fixes, removing compiler warnings, etc.Branch from develop
Develop currently represents work toward OpenHub Framework baseline. Direct commit to public branches is not allowed. Please submit all pull requests there, even bug fixes and minor improvements. Backports to previous version will be considered on a case-by-case basis.
Use short branch namesBranches used when submitting pull requests should preferably be named according to JIRA issues, e.g. 'feature/OHFJIRA-5
'. Otherwise, use succinct, lower-case, dash (-) delimited names, such as 'fix-warnings', 'fix-typo', etc. In
fork-and-edit cases, the GitHub default 'patch-1' is fine as well. This is important, because branch names show up in the merge commits that result from accepting pull requests and should be as expressive and concise as possible.
Branches used when submitting pull requests should preferably be named according to JIRA issues, e.g. 'feature/OHFJIRA-5
'. Otherwise, use succinct, lower-case, dash (-) delimited names, such as 'fix-warnings', 'fix-typo', etc. In
Use OpenHub Framework Code StyleThe complete
OpenHub Framework Code Style reference is available on the wiki, but here's a quick summary:
Please carefully follow the whitespace and formatting conventions already present in the framework.
- Spaces, not tabs. Tab should be converted to spaces.
- Unix (LF), not DOS (CRLF) line endings
- Eliminate all trailing whitespace
- Wrap Javadoc at 120 characters
- Aim to wrap code at 120 characters, but favor readability over wrapping
- Maximum size of one class should not exceed 700 lines.
- Preserve existing formatting; i.e. do not reformat code for its own sake
- Search the codebase using
git grep
and other tools to discover common naming conventions, etc. - UTF-8 encoding for Java sources
Add Apache license header to all new classes/*
* Copyright 2002-2016 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package ...;
Update Apache license header in modified files as necessaryAlways check the date range in the license header. For example, if you've modified a file in 2015 whose header still reads:
/*
* Copyright 2002-2011 the original author or authors.
Then be sure to update it to 2016 accordingly:
/*
* Copyright 2002-2016 the original author or authors.
Use @since tags for newly-added public API types and methodsFor example:
/**
* ...
*
* @author First Last
* @since 1.1
* @see ...
*/
Prepare Your CommitSubmit JUnit test cases for all behavior changesSearch the codebase to find related tests and add additional @Test
methods as appropriate. It is also acceptable to submit test cases on a per JIRA issue basis, for example:
package org.openhubframework.openhub.test;
/**
* Unit tests for OHF-123.
*
* @author FirstName LastName
*/
public class Ohf123Tests {
@Test
public void cornerOhf123() {
// ...
}
}
Squash commitsUse git rebase --interactive --autosquash
, git add --patch
, and other tools to "squash" multiple commits into a single atomic commit. In addition to the man pages for git, there are many resources online to help you understand how these tools work. The
Rewriting History section of Pro Git provides a good overview.
Use real name in git commitsPlease configure git to use your real first and last name for any commits you intend to submit as pull requests. For example, this is not acceptable:
Author: Nickname <user@mail.com>
Rather, please include your first and last name, properly capitalized:
Author: First Last <user@mail.com>
This helps ensure traceability and also goes a long way to ensuring useful output from tools like git shortlog
and others.
You can configure this via the account admin area in GitHub (useful for fork-and-edit cases); globally on your machine with
git config --global user.name "First Last"
git config --global user.email user@mail.com
or locally for the openhub-framework
repository only by omitting the '--global' flag:
cd openhub-framework
git config user.name "First Last"
git config user.email user@mail.com
Format commit messagesPlease read and follow the
Commit Guidelines section of Pro Git.
Most importantly, please format your commit messages in the following way (adapted from the commit template in the link above):
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here
Issue: OHFJIRA-1, OHFJIRA-2
- Use imperative statements in the subject line, e.g. "Fix broken Javadoc link".
- Begin the subject line with a capitalized verb, e.g. "Add, Prune, Fix, Introduce, Avoid, etc."
- Do not end the subject line with a period.
- Restrict the subject line to 50 characters or less if possible.
- Wrap lines in the body at 72 characters or less.
- Mention associated JIRA issue(s) at the end of the commit comment, prefixed with "Issue: " as above.
- In the body of the commit message, explain how things worked before this commit, what has changed, and how things work now.
Examples of commit messages:
Code Blocklanguage xml title #1
Clarification of contributing README
Added page to describe rules and principles how to contribute (https://openhubframework.atlassian.net/wiki/display/OHF/Rules+and+principles).
We strongly recommend discussing any serious submissions with the OpenHub Framework team prior to engaging in serious development work.
Issue: OHFJIRA-4
Code Block language xml title #2
Laying the foundation stone of redesigned admin GUI
Created new maven module ‘admin-console-client’ as module that holds all web resources of OpenHub admin console.
A build is realised with frontend-plugin. Only basic structure is created under src/main/resources/META-INF/resources/.
Location of resources is created with regard to scalability and customisation of build.
- source root dir for web resources is src/main/resources/META-INF/resources/
Issue: OHFJIRA-4
Run the Final ChecklistRun all tests prior to submissionSee the
building from source section for instructions. Make sure that all tests pass prior to submitting your pull request.
Submit your pull requestSubject line:
Follow the same conventions for pull request subject lines as mentioned above for commit message subject lines.
In the body:
- Explain your use case. What led you to submit this change? Why were existing mechanisms in the framework insufficient? Make a case that this is a general-purpose problem and that yours is a general-purpose solution, etc.
- Add any additional information and ask questions; start a conversation or continue one from JIRA.
- Mention the JIRA issue ID.
Note that for pull requests containing a single commit, GitHub will default the subject line and body of the pull request to match the subject line and body of the commit message. This is fine, but please also include the items above in the body of the request.
Mention your pull request on the associated JIRA issueAdd a comment to the associated JIRA issue(s) linking to your new pull request.
Expect discussion and reworkThe OpenHub team takes a very conservative approach to accepting contributions to the framework. This is to keep code quality and stability as high as possible, and to keep complexity at a minimum. Your changes, if accepted, may be heavily modified prior to merging. You will retain "Author:" attribution for your Git commits granted that the bulk of your changes remain intact. You may be asked to rework the submission for style (as explained above) and/or substance. Again, we strongly recommend discussing any serious submissions with the OpenHub Framework team prior to engaging in serious development work.
Note that you can always force push (git push -f
) reworked / rebased commits against the branch used to submit your pull request. In other words, you do not need to issue a new pull request when asked to make changes.
/*
* Copyright 2002-2016 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package ...;
Always check the date range in the license header. For example, if you've modified a file in 2015 whose header still reads:
/*
* Copyright 2002-2011 the original author or authors.
Then be sure to update it to 2016 accordingly:
/*
* Copyright 2002-2016 the original author or authors.
Use @since tags for newly-added public API types and methodsFor example:
/**
* ...
*
* @author First Last
* @since 1.1
* @see ...
*/
Prepare Your CommitSubmit JUnit test cases for all behavior changesSearch the codebase to find related tests and add additional @Test
methods as appropriate. It is also acceptable to submit test cases on a per JIRA issue basis, for example:
package org.openhubframework.openhub.test;
/**
* Unit tests for OHF-123.
*
* @author FirstName LastName
*/
public class Ohf123Tests {
@Test
public void cornerOhf123() {
// ...
}
}
Squash commitsUse git rebase --interactive --autosquash
, git add --patch
, and other tools to "squash" multiple commits into a single atomic commit. In addition to the man pages for git, there are many resources online to help you understand how these tools work. The
Rewriting History section of Pro Git provides a good overview.
Use real name in git commitsPlease configure git to use your real first and last name for any commits you intend to submit as pull requests. For example, this is not acceptable:
Author: Nickname <user@mail.com>
Rather, please include your first and last name, properly capitalized:
Author: First Last <user@mail.com>
This helps ensure traceability and also goes a long way to ensuring useful output from tools like git shortlog
and others.
You can configure this via the account admin area in GitHub (useful for fork-and-edit cases); globally on your machine with
git config --global user.name "First Last"
git config --global user.email user@mail.com
or locally for the openhub-framework
repository only by omitting the '--global' flag:
cd openhub-framework
git config user.name "First Last"
git config user.email user@mail.com
Format commit messagesPlease read and follow the
Commit Guidelines section of Pro Git.
Most importantly, please format your commit messages in the following way (adapted from the commit template in the link above):
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here
Issue: OHFJIRA-1, OHFJIRA-2
- Use imperative statements in the subject line, e.g. "Fix broken Javadoc link".
- Begin the subject line with a capitalized verb, e.g. "Add, Prune, Fix, Introduce, Avoid, etc."
- Do not end the subject line with a period.
- Restrict the subject line to 50 characters or less if possible.
- Wrap lines in the body at 72 characters or less.
- Mention associated JIRA issue(s) at the end of the commit comment, prefixed with "Issue: " as above.
- In the body of the commit message, explain how things worked before this commit, what has changed, and how things work now.
Examples of commit messages:
Code Blocklanguage xml title #1
Clarification of contributing README
Added page to describe rules and principles how to contribute (https://openhubframework.atlassian.net/wiki/display/OHF/Rules+and+principles).
We strongly recommend discussing any serious submissions with the OpenHub Framework team prior to engaging in serious development work.
Issue: OHFJIRA-4
Code Block language xml title #2
Laying the foundation stone of redesigned admin GUI
Created new maven module ‘admin-console-client’ as module that holds all web resources of OpenHub admin console.
A build is realised with frontend-plugin. Only basic structure is created under src/main/resources/META-INF/resources/.
Location of resources is created with regard to scalability and customisation of build.
- source root dir for web resources is src/main/resources/META-INF/resources/
Issue: OHFJIRA-4
Run the Final ChecklistRun all tests prior to submissionSee the
building from source section for instructions. Make sure that all tests pass prior to submitting your pull request.
/**
* ...
*
* @author First Last
* @since 1.1
* @see ...
*/
Submit JUnit test cases for all behavior changesSearch the codebase to find related tests and add additional @Test
methods as appropriate. It is also acceptable to submit test cases on a per JIRA issue basis, for example:
package org.openhubframework.openhub.test;
/**
* Unit tests for OHF-123.
*
* @author FirstName LastName
*/
public class Ohf123Tests {
@Test
public void cornerOhf123() {
// ...
}
}
Squash commitsUse git rebase --interactive --autosquash
, git add --patch
, and other tools to "squash" multiple commits into a single atomic commit. In addition to the man pages for git, there are many resources online to help you understand how these tools work. The
Rewriting History section of Pro Git provides a good overview.
@Test
methods as appropriate. It is also acceptable to submit test cases on a per JIRA issue basis, for example:package org.openhubframework.openhub.test;
/**
* Unit tests for OHF-123.
*
* @author FirstName LastName
*/
public class Ohf123Tests {
@Test
public void cornerOhf123() {
// ...
}
}
Use git rebase --interactive --autosquash
, git add --patch
, and other tools to "squash" multiple commits into a single atomic commit. In addition to the man pages for git, there are many resources online to help you understand how these tools work. The
Use real name in git commitsPlease configure git to use your real first and last name for any commits you intend to submit as pull requests. For example, this is not acceptable:
Author: Nickname <user@mail.com>
Rather, please include your first and last name, properly capitalized:
Author: First Last <user@mail.com>
This helps ensure traceability and also goes a long way to ensuring useful output from tools like git shortlog
and others.
You can configure this via the account admin area in GitHub (useful for fork-and-edit cases); globally on your machine with
git config --global user.name "First Last"
git config --global user.email user@mail.com
or locally for the openhub-framework
repository only by omitting the '--global' flag:
cd openhub-framework
git config user.name "First Last"
git config user.email user@mail.com
Format commit messagesPlease read and follow the
Commit Guidelines section of Pro Git.
Most importantly, please format your commit messages in the following way (adapted from the commit template in the link above):
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here
Issue: OHFJIRA-1, OHFJIRA-2
- Use imperative statements in the subject line, e.g. "Fix broken Javadoc link".
- Begin the subject line with a capitalized verb, e.g. "Add, Prune, Fix, Introduce, Avoid, etc."
- Do not end the subject line with a period.
- Restrict the subject line to 50 characters or less if possible.
- Wrap lines in the body at 72 characters or less.
- Mention associated JIRA issue(s) at the end of the commit comment, prefixed with "Issue: " as above.
- In the body of the commit message, explain how things worked before this commit, what has changed, and how things work now.
Author: Nickname <user@mail.com>
Author: First Last <user@mail.com>
git shortlog
and others.git config --global user.name "First Last"
git config --global user.email user@mail.com
openhub-framework
repository only by omitting the '--global' flag:cd openhub-framework
git config user.name "First Last"
git config user.email user@mail.com
Please read and follow the
Commit Guidelines section of Pro Git.Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary here
Issue: OHFJIRA-1, OHFJIRA-2
Examples of commit messages:
Code Block | ||||
---|---|---|---|---|
| ||||
Clarification of contributing README Added page to describe rules and principles how to contribute (https://openhubframework.atlassian.net/wiki/display/OHF/Rules+and+principles). We strongly recommend discussing any serious submissions with the OpenHub Framework team prior to engaging in serious development work. Issue: OHFJIRA-4 |
Code Block | ||||
---|---|---|---|---|
| ||||
Laying the foundation stone of redesigned admin GUI Created new maven module ‘admin-console-client’ as module that holds all web resources of OpenHub admin console. A build is realised with frontend-plugin. Only basic structure is created under src/main/resources/META-INF/resources/. Location of resources is created with regard to scalability and customisation of build. - source root dir for web resources is src/main/resources/META-INF/resources/ Issue: OHFJIRA-4 |
Run the Final ChecklistRun all tests prior to submissionSee the
building from source section for instructions. Make sure that all tests pass prior to submitting your pull request.
See the
building from source section for instructions. Make sure that all tests pass prior to submitting your pull request.Submit your pull requestSubject line:
Follow the same conventions for pull request subject lines as mentioned above for commit message subject lines.
In the body:
- Explain your use case. What led you to submit this change? Why were existing mechanisms in the framework insufficient? Make a case that this is a general-purpose problem and that yours is a general-purpose solution, etc.
- Add any additional information and ask questions; start a conversation or continue one from JIRA.
- Mention the JIRA issue ID.
Note that for pull requests containing a single commit, GitHub will default the subject line and body of the pull request to match the subject line and body of the commit message. This is fine, but please also include the items above in the body of the request.
Mention your pull request on the associated JIRA issueAdd a comment to the associated JIRA issue(s) linking to your new pull request.
Expect discussion and reworkThe OpenHub team takes a very conservative approach to accepting contributions to the framework. This is to keep code quality and stability as high as possible, and to keep complexity at a minimum. Your changes, if accepted, may be heavily modified prior to merging. You will retain "Author:" attribution for your Git commits granted that the bulk of your changes remain intact. You may be asked to rework the submission for style (as explained above) and/or substance. Again, we strongly recommend discussing any serious submissions with the OpenHub Framework team prior to engaging in serious development work.
Note that you can always force push (git push -f
) reworked / rebased commits against the branch used to submit your pull request. In other words, you do not need to issue a new pull request when asked to make changes.
Add a comment to the associated JIRA issue(s) linking to your new pull request.
Expect discussion and reworkThe OpenHub team takes a very conservative approach to accepting contributions to the framework. This is to keep code quality and stability as high as possible, and to keep complexity at a minimum. Your changes, if accepted, may be heavily modified prior to merging. You will retain "Author:" attribution for your Git commits granted that the bulk of your changes remain intact. You may be asked to rework the submission for style (as explained above) and/or substance. Again, we strongly recommend discussing any serious submissions with the OpenHub Framework team prior to engaging in serious development work.
Note that you can always force push (git push -f
) reworked / rebased commits against the branch used to submit your pull request. In other words, you do not need to issue a new pull request when asked to make changes.
git push -f
) reworked / rebased commits against the branch used to submit your pull request. In other words, you do not need to issue a new pull request when asked to make changes.