Guidelines for contributing code - KULeuvenNeuromechanics/PredSim GitHub Wiki

Create new branch

Create a dedicated branch to make your changes (meaningful name!). The branch can be in this repo or in your forked repo. To avoid conflicts later on, base your branch on the master branch in this repo. If you want to contribute multiple new/updated features, create a branch for each.

Write code

Follow general good practices:

• functions, variables, etc. need to have a meaningful name
• add comments to explain why you do something
• when you commit code to your branch, fill in commit summary and description
• test your changes, or ask someone else to test them. Preferably create a unit test for new functions: PredSim/Tests/test_(function name)
• Make sure the relevant documentation (readme) is updated.

Use this template for functions:

function [output_1] = meaningful_function_name(input_1, input_2)
% --------------------------------------------------------------------------
% meaningful_function_name
%   Explanation of what this function does. Length depends on function 
%   complexity. Include relevant citations. If applicable, provide an
%   example and/or refer to a unit test. 
% 
%
%   References
%   [1] cite a relevant paper if applicable
%
%   See also related_function_name
%
% INPUT:
%   - input_1 -
%   * brief description of input_1, including data type.
% 
%   - input_2 -
%   * brief description of input_2. For more complex inputs, such as structs,
%   include an example input.
%
%
% OUTPUT:
%   - output_1 -
%   * brief description of output_1
% 
% Original author: (First name Last name)
% Original date: (Using "30/May/2022" format avoids confusion)
% --------------------------------------------------------------------------

% your code here %

end % end of function

Pull request

Make a pull request (PR) to the master branch (of this repo)

• Set a meaningful name
• Fill in the description. Information you may want to provide includes:
  • short overview of changes
  • link issues that are closed by these changes (#number in text, or "Development" tab in side bar)
  • describe tests you ran and give outcome
  • proposed tests for reviewers to run
• Assign labels ("Labels" tab in side bar). Each PR should have at least one "Review:..." label, since we use these to allocate reviewers.
• Do not add requested reviewers, unless this person specifically agreed to review your PR.
• If you are a collaborator (i.e. have direct write access to this repo) select yourself as assignee, otherwise someone will be assigned to your PR.

The person making the PR is responsible to resolve any conflicts, also if they occur after initial submission.

Responsibilities of the assignee are:

• Keeping track that PR gets accepted within reasonable time.
• When approved, merge PR.
• If PR comes from branch in this repo, delete branch after merging.