diff --git a/docs/assets/images/favicon.png b/docs/assets/images/favicon.png new file mode 100644 index 0000000..6a24954 Binary files /dev/null and b/docs/assets/images/favicon.png differ diff --git a/docs/assets/images/logo.png b/docs/assets/images/logo.png new file mode 100644 index 0000000..3f2de90 Binary files /dev/null and b/docs/assets/images/logo.png differ diff --git a/docs/community/contributor-guide.md b/docs/community/contributor-guide.md deleted file mode 100644 index f7eebdb..0000000 --- a/docs/community/contributor-guide.md +++ /dev/null @@ -1,560 +0,0 @@ -# How to contribute to `physiopy` - -Welcome to the `physiopy` organisation! It's great news that you're -thinking about contributing! - -Working with many people from many different places is great, but -sometimes this means that code can become messy due to the many -different ways a contribution can be made. For this reason, we have set -up some guidelines for contributions - to help you get involved ASAP! If -you lack knowledge in python development / github use / physiological -data handling, don't be scared! Try to jump in anyway. Most of the -original contributors learned these things exactly this way - jumping in -and hoping to fall in the right way without breaking too many bones. Do -you want to jump in but don't exactly know where/how? You can drop a few -lines in [gitter](https://gitter.im/phys2bids/community), so we can help -you find something that suits you! Already know what you're looking for -in this guide? Jump to the following sections: - -## Aims of physiopy - -`physiopy` is a **very** young project developed by a bunch of -researchers from the two different sides of the Atlantic Ocean (for -now). Our main goal is to help collect, analyse and share physiological -data, interfacing with (MRI) neuroimaging. We're trying to do so by: - -1. Writing packages to make a user-friendly pipeline to deal with - physiological data. -2. Writing packages that take into account the use of this - physiological data in combination with neuroimaging (MRI) analysis. -3. Providing documentation containing tips and strategies on how to - collect such data and use our packages. -4. Help set a standard for these data, albeit without forcing users to - use it. -5. Be an excuse for educational purposes on topics like Git/GitHub, - Python3, physiology and related tools/topics. - -## Joining the conversation - -We're trying to keep all conversation related to project development in -GitHub [issues](https://github.com/physiopy/phys2bids/issues). We -maintain a [gitter chat room](https://gitter.im/physiopy/community) for -more informal conversations and general project updates. We also have a -dev call once a month - specifically the second Thursday of the month! -If you want to participate, drop a line in gitter! When interacting in -the common channels, please adhere to our [code of -conduct](conduct.html). - -## Contributions - -### Contributing with small documentation changes - -If you are new to GitHub and just have a small documentation change -recommendation (such as: typos detection, small improvements in the -content, ...), please open an issue in the relative project, and label -it with the "Documentation" label. Chances are those types of changes -are easily doable with GitHub's online editor, which means you can do -them, or ask for help from the developers! - -### Contributing with user testing - -Another, non-coding friendly way to contribute to `physiopy` is by -testing the packages. There are different kinds of tests, but to -simplify things you can think mainly about automatic tests and user -tests. To know more about **Automatic tests**, you can read the [testing -section](#automatic-testing). **User testing** are warm, human, emotional and -opinionated tests that not only check that the code is doing what it -needs to do, but also whether there's a better way to do it - namely -better reports, clearer screen outputs, warnings and exceptions, -unexpected bugs that have to be corrected. If you want to perform one, -open an issue on GitHub or drop a comment in Gitter, refer to this -[blueprint](https://docs.google.com/document/d/1b6wc7JVDs3vi-2IqGg_Ed_oWKbZ6siboAJHf55nodKo/edit?usp=sharing) -and don't be afraid to ask questions! - -### Contributing with test files - -At `physiopy` we always try to imagine and support every possible -setting out there. However, our imagination has a limit - but if you -think our packages should process a specific format/setting that you -have, we're more than glad to do so! To make it happen, we need an -example of the file we want to process, so you will have to share it -with us (and the rest of the world)! The contribution can be a full file -of data that you already acquired, a part of that file (pay attention to -what is the minimum you need to share!), or mock data. The file -contribution should come with a json file of the same name that contains -the necessary information to run `phys2bids` on that file contribution. -There is a [json blueprint in -OSF](https://mfr.de-1.osf.io/render?url=https://osf.io/jrnxv/?direct%26mode=render%26action=download%26mode=render), -you can download it and adapt it. Note that the frequency list **has to -be expressed in Hz** as an integer or float. To contribute with a test -file, open an Issue in GitHub and label it with *Test*. We'll help you -add the file in our [OSF](https://osf.io/3txqr/) space. We're extremely -grateful for this type of contribution - so grateful that we asked -allcontributors to add a dedicated category! - -### Contributing documentation through GitHub - -We use [readthedocs](https://readthedocs.org/) to create our -documentation. Every contribution is welcome and it follows the same -steps as a code contribution, explained below. - -### Contributing code through GitHub - -This section covers 90% of the contributions a project like `physiopy` -receives - code, documentation and tests. The best way to make this kind -of contribution, in a nutshell, is to: 1. Open an issue with the -intended modifications. 2. Label it, discuss it, (self-)assign it. 3. -Open a Pull Request (PR) to resolve the issue and label it. 4. Wait for -a review, discuss it or comply, repeat until ready. Issues and PR chats -are great to maintain track of the conversation on the contribution. -They are based upon GitHub-flavoured -[Markdown](https://daringfireball.net/projects/markdown). GitHub has a -helpful page on [getting started with writing and formatting Markdown on -GitHub](https://help.github.com/articles/getting-started-with-writing-and-formatting-on-github). - -### Contributing with Pull Requests Reviews - -A big challenge of software development is merging code accurately -without having to wait too much time. For this reason, Reviewers for PRs -are more than welcome! It is a task that requires some experience, but -it's very necessary! Read the [related section below](#reviewing-prs) to -start! - -## Issues and Milestones - -At `physiopy`, we use Issues and Milestones to keep track of and -organise our workflow. **Issues** describe pieces of work that need to -be completed to move the project forwards. We try to keep them as simple -and clear as possible: an issue should describe a unitary, possibly -small piece of work (unless it's about refactoring). Don't be scared of -opening many issues at once, if it makes sense! Just check that what -you're proposing is not listed in a previous issue (open or closed) yet -(we don't like doubles). Issues get labelled. That helps the -contributors to know what they're about. Check the label list to know -what types are there, and use them accordingly! Issues can also be -**assigned**. If you want to work on an assigned issue, ask permission -first! - **Milestones** set the higher level workflow. They sketch -deadlines and important releases. Issues are assigned to these -milestones by the maintainers. If you feel that an issue should be -assigned to a specific milestone but the maintainers have not done so, -discuss it in the issue chat or in Gitter! We might have just missed it, -or we might not (yet) see how it aligns with the overall project -structure/milestone. - -## Labels - -The current list of labels are -[here](https://github.com/physiopy/phys2bids/labels). They can be used -for **Issues**, **PRs**, or both. We use -[auto](https://github.com/intuit/auto) to automate our semantic -versioning and Pypi upload, so **it's extremely important to use the -right PR labels**! - -### Issue & PR labels - -- ![Documentation](https://img.shields.io/badge/-Documentation-1D70CF?style=flat-square) Improvements or additions to documentation. This - category includes (but is not limited to) docs pages, docstrings, - and code comments. - -- ![Duplicate](https://img.shields.io/badge/-Duplicate-CFD3D7?style=flat-square) Whatever this is, it exists already! Maybe it's a closed - Issue/PR, that should be reopened. - -- ![Enhancement](https://img.shields.io/badge/-Enhancement-A2EEEF?style=flat-square) New features added or requested. This normally goes with a `minormod` label for PRs. - -- ![Outreach](https://img.shields.io/badge/-Outreach-0E8A16?style=flat-square) As part of the scientific community, we care about outreach. Check the relevant section about it, but know that this - Issue/PR contains information or tasks about abstracts, talks, - demonstrations, papers. - -- ![Paused](https://img.shields.io/badge/-Paused-F7C38C?style=flat-square) Issue or PR should not be worked on until the resolution of other issues or PRs. - -- ![released](https://img.shields.io/badge/-released-ffffff?style=flat-square) This Issue or PR has been released. - -- ![Testing](https://img.shields.io/badge/-Testing-FFB5B4?style=flat-square) This is for testing features, writing tests or producing testing code. Both user testing and CI testing! - -- ![Urgent](https://img.shields.io/badge/-Urgent-FFF200?style=flat-square) If you don't know where to start, start here! This is probably related to a milestone due soon! - -### Issue-only labels - -- ![BrainHack](https://img.shields.io/badge/-BrainHack-000000?style=flat-square) This issue is suggested for BrainHack participants! - -- ![Bug](https://img.shields.io/badge/-Bug-D73A4A?style=flat-square) Something isn't working. It either breaks the code or has an - unexpected outcome. - -- ![Community](https://img.shields.io/badge/-Community-E2C7FC?style=flat-square) This issue contains information about the `physiopy` - community (e.g. the next developer call) - -- ![Discussion](https://img.shields.io/badge/-Discussion-1C778C?style=flat-square) Discussion of a concept or implementation. These Issues - are prone to be open ad infinitum. Jump in the conversation if you - want! - -- ![Good first issue](https://img.shields.io/badge/-Good%20first%20issue-4E2A84?style=flat-square) Good for newcomers. These issues calls for a - **fairly** easy enhancement, or for a change that helps/requires - getting to know the code better. They have educational value, and - for this reason, unless urgent, experts in the topic should refrain - from closing them - but help newcomers closing them. - -- ![Hacktoberfest](https://img.shields.io/badge/-Hacktoberfest-FF7518?style=flat-square) Dedicated to the hacktoberfest event, so that people - can help and feel good about it (and show it with a T-shirt!). - **Such commits will not be recognised in the all-contributor table, - unless otherwise specified**. - -- ![Help wanted](https://img.shields.io/badge/-Help%20wanted-57DB1A?style=flat-square) Extra attention is needed here! It's a good place to have a look! - -- ![Refactoring](https://img.shields.io/badge/-Refactoring-9494FF?style=flat-square) Improve nonfunctional attributes. Which means rewriting - the code or the documentation to improve performance or just because - there's a better way to express those lines. It might create a - `majormod` PR. - -- ![Question](https://img.shields.io/badge/-Question-D876E3?style=flat-square) Further information is requested, from users to - developers. Try to respond to this! - -- ![Wontfix](https://img.shields.io/badge/-Wontfix-ffffff?style=flat-square) This will not be worked on, until further notice. - -### PR-only labels - -#### Labels for semantic release and changelogs - -- ![BugFIX](https://img.shields.io/badge/-BugFIX-D73A4A?style=flat-square) These PRs close an issue labelled `Bug`. They also increase - the semantic versioning for fixes (+0.0.1). - - - ![dependencies](https://img.shields.io/badge/-dependencies-0366D6?style=flat-square) Pull requests that update a dependency file - -- ![Documentation](https://img.shields.io/badge/-Documentation-1D70CF?style=flat-square) See above. This PR won't trigger a release, but it will be reported in the changelog. - -- ![Majormod](https://img.shields.io/badge/-Majormod-05246D?style=flat-square) These PRs call for a new major release (+1.0.0). This - means that the PR is breaking backward compatibility. - -- ![Minormod](https://img.shields.io/badge/-Minormod-05246D?style=flat-square) This PR generally closes an `Enhancement` issue. It increments the minor version (0.+1.0) - -- ![Minormod-breaking](https://img.shields.io/badge/-Minormod–breaking-05246D?style=flat-square) This label should be used during development stages (<1.0.0) only. These PRs call for a new minor release during development (0.+1.0) that **will** break backward compatibility. - -- ![Internal](https://img.shields.io/badge/-Internal-ffffff?style=flat-square) This PR contains changes to the internal API. It won't - trigger a release, but it will be reported in the changelog. - -- ![Testing](https://img.shields.io/badge/-Testing-FFB5B4?style=flat-square) See above. This PR won't trigger a release, but it will be - reported in the changelog. - -- ![Skip release](https://img.shields.io/badge/-Skip%20release-ffffff?style=flat-square) This PR will **not** trigger a release. - -- ![Release](https://img.shields.io/badge/-Release-ffffff?style=flat-square) This PR will force the trigger of a release. - -#### Other labels - -- ![Invalid](https://img.shields.io/badge/-Invalid-960018?style=flat-square): These PRs don't seem right. They actually seem so not - right that they won't be further processed. This label invalidates a - Hacktoberfest contribution. If you think this is wrong, start a - discussion in the relevant issue (or open one if missing). Reviewers - are asked to give an explanation for the use of this label. - -### Good First Issues - -Good First Issues are issues that are either very simple, or that help -the contributor get to know the programs or the languages better. We use -it to help contributors with less experience to learn and familiarise -with Git, GitHub, Python3, and physiology. We invite more expert -contributors to avoid those issues, leave them to beginners and possibly -help them out in the resolution of the issue. However, if the issue is -left unassigned or unattended for long, and it's considered important or -urgent, anyone can tackle it. - -## Contribution workflow - -There are many descriptions of a good contribution workflow out there. -For instance, we suggest to have a look at [tedana's workflow](https://github.com/ME-ICA/tedana/blob/master/CONTRIBUTING.md#making-a-change). -At `physiopy`, we follow a very similar workflow. The only three -differences are: - -- If you see an open issue that you would like to work on, check if it - is assigned. If it is, ask the assignee if they need help or want to - be substituted before starting to work on it. -- We ask you to test the code locally before merging it, and then, if - possible, write some automatic tests for the code to be run in our - Continuous Integration! Check the testing section below to know - more. -- We suggest opening a draft PR as soon as you can - so it's easier - for us to help you! - -See our [complete documentation](CONTRIBUTING.md#contributing) on the matter - -## Pull Requests - -To improve understanding pull requests "at a glance" and use the power -of `auto`, we use the labels listed above. Multiple labels can be -assigned to a PR - in fact, all those that you think are relevant. We -strongly advise to keep the changes you're introducing with your PR -limited to your original goal. Adding to the scope of your PR little -style corrections or code refactoring here and there in the code that -you're already modifying is a great help, but when they become too much -(and they are not relevant to your PR) they risk complicating the nature -of the PR and the reviewing process. It is much better to open another -PR with the objective of doing such corrections! Moreover, if you're -tempted to assign more than one label that would trigger a release (e.g. -bug and minormod or bug and majormod, etc.), you might want to split your PR -instead. When opening a pull request, assign it at least one label. - -We encourage you to open a PR as soon as possible - even before you -finish working on them. This is useful especially to you - so that you -can receive comments and suggestions early on, rather than having to -process a lot of comments in the final review step! However, if it's an -incomplete PR, please open a **Draft PR**. That helps us process PRs by -knowing which one to have a look first - and how picky to be when doing -so. - -Reviewing PRs is a time consuming task and it can be stressful for both -the reviewer and the author. Avoiding wasting time and the need of -little fixes - such as fixing grammar mistakes and typos, styling code, -or adopting conventions - is a good start for a successful (and quick) -review. Before graduating a Draft PR to a PR ready for review, please -check that: - -- You did all you wanted to include in your PR. If at a later stage - you realize something is missing and it's not a minor thing, you - will need to open a new PR. -- If your contribution contains code or tests, you ran and passed all - of the tests locally with [pytest](#automatic-testing). -- If you're writing documentation, you built it locally with - sphinx and the format is what you intended. -- Your code is harmonious with the rest of the code - no repetitions - of any sort! - -Your code respects the [adopted Style](#style-guide), especially if: - -- Your code is lintered adequately and respects the [PEP8](https://www.python.org/dev/peps/pep-0008/) convention. -- Your docstrings follow the [numpydoc](https://numpydoc.readthedocs.io/en/latest/format.html) convention. -- There are no typos or grammatical mistakes and the text is fluid. - -- The code is sufficiently commented and the comments are clear. - -- Your PR title is clear enough to be meaningful when appended to the version changelog. - -- You have the correct labels. - -### Before merging - -To be merged, PRs have to: - -1. Pass all the CircleCI tests, and possibly all the codecov checks. -2. Have the necessary amount of approving reviews, even if you're a - long time contributor. - - Note : You can ask one (or more) contributor to do - that review, if you think they align more with the content of your - PR. You need **one** review for documentation, tests, and small - changes, and **two** reviews for bugs, refactoring and enhancements. -3. Have at least a release-related label (or a `Skip - release` label). -4. Have a short title that clearly explains in one sentence the aim of - the PR. -5. Contain at least a unit test for your contribution, if the PR - contains code (it would be better if it contains an integration or - function test and all the breaking tests necessary). If you're not - confident about writing tests, it is possible to refer to an issue - that asks for the test to be written, or another (Draft) PR that - contains the tests required. - -As we're trying to maintain at least 90% code coverage, you're strongly -encouraged to write all of the tests necessary to keep coverage above -that threshold. If coverage drops too low, you might be asked to add -more tests and/or your PR might be rejected. See the [Automatic testing](#automatic-testing) section. - -Don't merge your own pull request! That's a task for the main reviewer -of your PR or the project manager. Remember that the project manager -doesn't have to be a reviewer of your PR! - -## Reviewing PRs - -Reviewing PRs is an extremely important task in collaborative -development. In fact, it is probably the task that requires the most -time in the development, and it can be stressful for both the reviewer -and the author. Remember that, as a PR Reviewer, you are guaranteeing -that the changes work and integrate well with the rest of the -repository, hence **you are responsible for the quality of the -repository and its next version release**. If they don't integrate -well, later PR reviewers might have to ask for broader changes than -expected. - -There are many best practices to review code online, for -instance [this medium blog post](https://medium.com/an-idea/the-code-review-guide-9e793edcd683), but -here are some good rules of thumbs that we need to follow while -reviewing PRs: - -- Be **respectful** to the PR authors and be clear in what you are - asking/suggesting - remember that, like you, they are contributing - their spare time and doing their best job! - -- If there is a *Draft PR*, you can comment on its development in the - message board or making "Comment" reviews. Don't ask for changes, - and especially, **don't approve the PR** - -- If the PR graduated *from Draft to full PR*, check that it follows the - sections [Pull requests](#pull-requests) and [Style Guide](#style-guide) of these - guidelines. If not, invite the author to do so before starting a - review. -- **Don't limit your review to the parts that are changed**. Look at - the entire file, see if the changes fit well in it, and see if the - changes are properly addressed everywhere in the code - in the - documentation, in the tests, and in other functions. Sometimes the - differences reported don't show the full impact of the PR in the - repository! -- If your want to make Pull Requests an educational process, invite - the author of the PR to make changes before actually doing them - yourself. Request changes via comments or in the message board or by - checking out the PR locally, making changes and then submitting a PR - to the author's branch. -- If you decide to use the suggestion tool in reviews, or to start a - PR to the branch under review, please alert the Project Manager. - Bots might automatically assign you contribution types that will - have to be removed (remember, your contribution in this case is - "Reviewer"). Instead of starting a PR to the branch under review, - think about opening a new PR with those modifications (unless they - are needed to pass tests), and alert the Main Reviewer. In any case - **don't commit directly to the branch under review**! -- If you're reviewing documentation, build it locally with [`sphinx-build`](https://www.sphinx-doc.org/en/master/man/sphinx-build.html) command. -- If you're asking for changes, **don't approve the PR**. Approve it - only after everything was sufficiently addressed. Someone else might - merge the PR in taking your word for granted. -- If you are the main reviewer, and the last reviewer required to - approve the PR, merge the PR! - -Before approving and/or merging PRs, be sure that: - -- All the tests in CircleCI/Azure pass without errors. -- Prefereably, codecov checks pass as well. If they don't, discuss - what to do. -- The title describes the content of the PR clearly enough to be - meaningful on its own - remember that it will appear in the version - changelog! -- The PR has the appropriate labels to trigger the appropriate version - release and update the contributors table. - -### Main reviewer - -At `physiopy` we use the *Assignees* section of a PR to mark the -**main reviewer** for that PR. The main reviewer is the primary person -responsible **for the quality of the repository and its next version release**, - as well as **for the behaviour of the other reviewers**. - -***The main reviewer takes care of the reviewing process of the PR, in particular:*** - -- Invites the reviewers to finish their review in a relatively - short time. - -- Checks that all elements of this document were respected, - especially the part about [Pull Requests](#pull-requests). - -- Invites other Reviewers to respect this document, especially - the part about [reviews](#reviewing-prs), helps them in doing - so, and checks that they do. - -- If a Reviewer keeps not respecting this document, flags them - to the project manager. - -- Decides what to do in case of a coverage decrease (in - *codecov/patch*). - -***In case of missing tests or updates to user documentation:*** - -- Asks for more documentation or tests before approving the - PR, *or* - -- Checks that the appropriate issues have been opened to - address the lack of documentation or tests (1 issue per item), *or* - -- Double-checks that the title is clear and the labels are correct to - trigger an appropriate `auto` release - feel free to change them. - -- Main reviewer **Is the one that is going to merge the PR.** - -***After the PR has been merged and a new release has been triggered, checks that:*** - -- The documentation was updated correctly (if changed). -- The Pypi version of the repository coincides with the new release (if changed). -- New contributors or forms of contributions were correctly added in the README (if changed). - -## Style Guide - -Docstrings should follow -[numpydoc](https://numpydoc.readthedocs.io/en/latest/format.html) -convention. We encourage extensive documentation. The python code itself -should follow [PEP8](https://www.python.org/dev/peps/pep-0008/) -convention whenever possible: there are continuous integration tests -checking that! You can use linters to help you write your code following -style conventions. Linters are add-ons that you can run on the written -script file. We suggest the use of **flake8** for Python 3. Many editors -(Atom, VScode, Sublimetext, \...) support addons for online lintering, -which means you'll see warnings and errors while you write the code - -check out if your does! - -Since we adopt [auto](https://intuit.github.io/auto/home.html), the PR -title will be automatically reported as part of the changelog when -updating versions. Try to describe in one (short) sentence what your PR -is about - possibly using the imperative and starting with a capital -letter. For instance, a good PR title could be: -`Implement support for files` or -`Reorder dictionary entries`, rather than ` support` or -`reorders keys`. - -## Automatic Testing - -`physiopy` uses Continuous Integration (CI) to make life easier. In -particular, we use the [CircleCI](https://circleci.com/) platform to run -automatic testing! **Automatic tests** are cold, robotic, emotionless, -and opinionless tests that check that the program is doing what it is -expected to. They are written by the developers and run (by CircleCI) -every time they send a Pull Request to `physiopy` repositories. They -complement the warm, human, emotional and opinionated **user tests**, as -they tell us if a piece of code is failing. CircleCI uses -[pytest](https://docs.pytest.org/en/latest/) to run the tests. The great -thing about it is that you can run it in advance on your local version -of the code! We can measure the amount of code that is tested with -[codecov](https://docs.pytest.org/en/latest/), which is an indication of -how reliable our packages are! We try to maintain a 90% code coverage, -and for this reason, PR should contain tests! The four main type of -tests we use are: - -1. Unit tests : - - Unit tests check that a minimal piece of code is doing what it - should be doing. Normally this means calling a function with - some mock parameters and checking that the output is equal to - the expected output. For example, to test a function that adds - two given numbers together (1 and 3), we would call the function - with those parameters, and check that the output is 4. - -2. Breaking tests - - Breaking tests are what you expect - they check that the program - is breaking when it should. This means calling a function with - parameters that are expected **not** to work, and check that it - raises a proper error or warning. - -3. Integration tests - - Integration tests check that the code has an expected output, - being blind to its content. This means that if the program - should output a new file, the file exists - even if it's empty. - This type of tests are normally run on real data and call the - program itself. For instance, documentation PRs should check - that the documentation page is produced! - -4. Functional tests - - If integration tests and unit tests could have babies, those - would be functional tests. In practice, this kind of tests check - that an output is produced, and *also* that it contains what it - should contain. If a function should output a new file or an - object, this test passes only if the file exists *and* it is - like we expect it to be. They are run on real or mock data, and - call the program itself or a function. - -## Recognising contributors - -We welcome and recognize [all -contributions](https://allcontributors.org/docs/en/specification) from -documentation to testing to code development. You can see a list of -current contributors in the README (kept up to date by the [all -contributors bot](https://allcontributors.org/docs/en/bot/overview)). - -**Thank you!** - -*--- Based on contributing guidelines from the [STEMMRoleModels](https://github.com/KirstieJane/STEMMRoleModels) project.* diff --git a/docs/community/contributorfile.md b/docs/community/contributorfile.md deleted file mode 100644 index edbea37..0000000 --- a/docs/community/contributorfile.md +++ /dev/null @@ -1,572 +0,0 @@ -[How to contribute to `physiopy`](#contributorfile) -=============================== - -Welcome to the `physiopy` organisation! It's great news that you're -thinking about contributing! - -Working with many people from many different places is great, but -sometimes this means that code can become messy due to the many -different ways a contribution can be made. For this reason, we have set -up some guidelines for contributions - to help you get involved ASAP! If -you lack knowledge in python development / github use / physiological -data handling, don't be scared! Try to jump in anyway. Most of the -original contributors learned these things exactly this way - jumping in -and hoping to fall in the right way without breaking too many bones. Do -you want to jump in but don't exactly know where/how? You can drop a few -lines in [gitter](https://gitter.im/phys2bids/community), so we can help -you find something that suits you! Already know what you\'re looking for -in this guide? Jump to the following sections: - -- [Aims of physiopy](#aims) -- [Join the conversation](#joinconvo) -- [Contributions](#contributiontypes) - - [Contributing with small documentation changes](#smalldocs) - - [Contributing with User testing](#usertests) - - [Contributing with test files](#testfile) - - [Contributing documentation through GitHub](#documenting) - - [Contributing code through GitHub](#code) - - [Contributing with Pull Requests Review](#reviews) -- [Issues and Milestones](#issuesmilestones) -- [Labels](#labeltypes) - - [Issues & PRs labels](#issueprlabels) - - [Issues labels](#issuelabel) - - [PRs labels](#prlabel) - - [Good First Issues](#g1i) -- [Contribution workflow](#workflow) -- [Pull Requests](#pr) -- [Reviewing PRs](#reviewing) -- [Style Guide](#styling) -- [Automatic Testing](#testing) -- [Recognizing contributors](#recognising) - -[Aims of physiopy](#aims) -============================ - -`physiopy` is a **very** young project developed by a bunch of -researchers from the two different sides of the Atlantic Ocean (for -now). Our main goal is to help collect, analyse and share physiological -data, interfacing with (MRI) neuroimaging. We're trying to do so by: - -1. Writing packages to make a user-friendly pipeline to deal with - physiological data. -2. Writing packages that take into account the use of this - physiological data in combination with neuroimaging (MRI) analysis. -3. Providing documentation containing tips and strategies on how to - collect such data and use our packages. -4. Help set a standard for these data, albeit without forcing users to - use it. -5. Be an excuse for educational purposes on topics like Git/GitHub, - Python3, physiology and related tools/topics. - -[Joining the conversation](#joinconvo) --------------------------------------- - -We're trying to keep all conversation related to project development in -GitHub [issues](https://github.com/physiopy/phys2bids/issues). We -maintain a [gitter chat room](https://gitter.im/physiopy/community) for -more informal conversations and general project updates. We also have a -dev call once a month - specifically the second Thursday of the month! -If you want to participate, drop a line in gitter! When interacting in -the common channels, please adhere to our [code of -conduct](conduct.html). - -[Contributions](#contributiontypes) --------------------------------------- - -### [Contributing with small documentation changes](#smalldocs) - -If you are new to GitHub and just have a small documentation change -recommendation (such as: typos detection, small improvements in the -content, ...), please open an issue in the relative project, and label -it with the "Documentation" label. Chances are those types of changes -are easily doable with GitHub\'s online editor, which means you can do -them, or ask for help from the developers! - -### [Contributing with User testing](#usertests) - -Another, non-coding friendly way to contribute to `physiopy` is by -testing the packages. There are different kinds of tests, but to -simplify things you can think mainly about automatic tests and user -tests. To know more about **Automatic tests**, you can read the [testing -section](#testing). **User testing** are warm, human, emotional and -opinionated tests that not only check that the code is doing what it -needs to do, but also whether there's a better way to do it - namely -better reports, clearer screen outputs, warnings and exceptions, -unexpected bugs that have to be corrected. If you want to perform one, -open an issue on GitHub or drop a comment in Gitter, refer to this -[blueprint](https://docs.google.com/document/d/1b6wc7JVDs3vi-2IqGg_Ed_oWKbZ6siboAJHf55nodKo/edit?usp=sharing) -and don't be afraid to ask questions! - -### [Contributing with test files](#testfile) - -At `physiopy` we always try to imagine and support every possible -setting out there. However, our imagination has a limit - but if you -think our packages should process a specific format/setting that you -have, we're more than glad to do so! To make it happen, we need an -example of the file we want to process, so you will have to share it -with us (and the rest of the world)! The contribution can be a full file -of data that you already acquired, a part of that file (pay attention to -what is the minimum you need to share!), or mock data. The file -contribution should come with a json file of the same name that contains -the necessary information to run `phys2bids` on that file contribution. -There is a [json blueprint in -OSF](https://mfr.de-1.osf.io/render?url=https://osf.io/jrnxv/?direct%26mode=render%26action=download%26mode=render), -you can download it and adapt it. Note that the frequency list **has to -be expressed in Hz** as an integer or float. To contribute with a test -file, open an Issue in GitHub and label it with *Test*. We'll help you -add the file in our [OSF](https://osf.io/3txqr/) space. We're extremely -grateful for this type of contribution - so grateful that we asked -allcontributors to add a dedicated category! - -### [Contributing documentation through GitHub](#documenting) - -We use [readthedocs](https://readthedocs.org/) to create our -documentation. Every contribution is welcome and it follows the same -steps as a code contribution, explained below. - -### [Contributing code through GitHub](#code) - -This section covers 90% of the contributions a project like `physiopy` -receives - code, documentation and tests. The best way to make this kind -of contribution, in a nutshell, is to: 1. Open an issue with the -intended modifications. 2. Label it, discuss it, (self-)assign it. 3. -Open a Pull Request (PR) to resolve the issue and label it. 4. Wait for -a review, discuss it or comply, repeat until ready. Issues and PR chats -are great to maintain track of the conversation on the contribution. -They are based upon GitHub-flavoured -[Markdown](https://daringfireball.net/projects/markdown). GitHub has a -helpful page on [getting started with writing and formatting Markdown on -GitHub](https://help.github.com/articles/getting-started-with-writing-and-formatting-on-github). - -### [Contributing with Pull Requests Reviews](#reviews) - -A big challenge of software development is merging code accurately -without having to wait too much time. For this reason, Reviewers for PRs -are more than welcome! It is a task that requires some experience, but -it's very necessary! Read the [related section below](#reviewing) to -start! - -[Issues and Milestones](#issuesmilestones) ------------------------------------------- - -At `physiopy`, we use Issues and Milestones to keep track of and -organise our workflow. **Issues** describe pieces of work that need to -be completed to move the project forwards. We try to keep them as simple -and clear as possible: an issue should describe a unitary, possibly -small piece of work (unless it's about refactoring). Don't be scared of -opening many issues at once, if it makes sense! Just check that what -you're proposing is not listed in a previous issue (open or closed) yet -(we don't like doubles). Issues get labelled. That helps the -contributors to know what they're about. Check the label list to know -what types are there, and use them accordingly! Issues can also be -**assigned**. If you want to work on an assigned issue, ask permission -first! - **Milestones** set the higher level workflow. They sketch -deadlines and important releases. Issues are assigned to these -milestones by the maintainers. If you feel that an issue should be -assigned to a specific milestone but the maintainers have not done so, -discuss it in the issue chat or in Gitter! We might have just missed it, -or we might not (yet) see how it aligns with the overall project -structure/milestone. - -[Labels](#labeltypes) --------------------------------------- - -The current list of labels are -[here](https://github.com/physiopy/phys2bids/labels). They can be used -for **Issues**, **PRs**, or both. We use -[auto](https://github.com/intuit/auto) to automate our semantic -versioning and Pypi upload, so **it\'s extremely important to use the -right PR labels**! - -### [Issue & PR labels](#issueprlabels) - -- Documentation: Improvements or additions to documentation. This - category includes (but is not limited to) docs pages, docstrings, - and code comments. -- Duplicate: Whatever this is, it exists already! Maybe it's a closed - Issue/PR, that should be reopened. -- Enhancement: New features added or requested. This normally goes - with a `minormod` label for PRs. -- Outreach: As part of the scientific community, we care about - outreach. Check the relevant section about it, but know that this - Issue/PR contains information or tasks about abstracts, talks, - demonstrations, papers. -- Paused: Issue or PR should not be worked on until the resolution of - other issues or PRs. -- Testing: This is for testing features, writing tests or producing - testing code. Both user testing and CI testing! -- Urgent: If you don\'t know where to start, start here! This is - probably related to a milestone due soon! - -### [Issue-only labels](#issuelabel) - -- Bug: Something isn't working. It either breaks the code or has an - unexpected outcome. -- Community: This issue contains information about the `physiopy` - community (e.g. the next developer call) -- Discussion: Discussion of a concept or implementation. These Issues - are prone to be open ad infinitum. Jump in the conversation if you - want! -- Good first issue: Good for newcomers. These issues calls for a - **fairly** easy enhancement, or for a change that helps/requires - getting to know the code better. They have educational value, and - for this reason, unless urgent, experts in the topic should refrain - from closing them - but help newcomers closing them. -- Hacktoberfest: Dedicated to the hacktoberfest event, so that people - can help and feel good about it (and show it with a T-shirt!). - **Such commits will not be recognised in the all-contributor table, - unless otherwise specified**. -- Help wanted: Extra attention is needed here! It's a good place to - have a look! -- Refactoring: Improve nonfunctional attributes. Which means rewriting - the code or the documentation to improve performance or just because - there's a better way to express those lines. It might create a - `majormod` PR. -- Question: Further information is requested, from users to - developers. Try to respond to this! -- Wontfix: This will not be worked on, until further notice. - -### [PR-only labels](#prlabel) - -#### Labels for semantic release and changelogs - -- Majormod: These PRs call for a new major release (+1.0.0). This - means that the PR is breaking backward compatibility. -- Minormod: These PRs call for a new minor release (0.+1.0). This - means that the PR is **not** breaking backward compatibility. -- BugFIX: These PRs close an issue labelled `bug`. They also increase - the semantic versioning for fixes (+0.0.1). -- Internal: This PR contains changes to the internal API. It won\'t - trigger a release, but it will be reported in the changelog. -- Documentation: See above. This PR won\'t trigger a release, but it - will be reported in the changelog. -- Testing: See above. This PR won\'t trigger a release, but it will be - reported in the changelog. -- Skip release: This PR will **not** trigger a release. -- Release: This PR will force the trigger of a release. - -#### Other labels - -- Invalid: These PRs don't seem right. They actually seem so not - right that they won't be further processed. This label invalidates a - Hacktoberfest contribution. If you think this is wrong, start a - discussion in the relevant issue (or open one if missing). Reviewers - are asked to give an explanation for the use of this label. - -### [Good First Issues](#g1i) - -Good First Issues are issues that are either very simple, or that help -the contributor get to know the programs or the languages better. We use -it to help contributors with less experience to learn and familiarise -with Git, GitHub, Python3, and physiology. We invite more expert -contributors to avoid those issues, leave them to beginners and possibly -help them out in the resolution of the issue. However, if the issue is -left unassigned or unattended for long, and it's considered important or -urgent, anyone can tackle it. - -[Contribution workflow](#workflow) --------------------------------------- - -There are many descriptions of a good contribution workflow out there. -For instance, we suggest to have a look at [tedana's workflow](https://github.com/ME-ICA/tedana/blob/master/CONTRIBUTING.md#making-a-change). -At `physiopy`, we follow a very similar workflow. The only three -differences are: - -- If you see an open issue that you would like to work on, check if it - is assigned. If it is, ask the assignee if they need help or want to - be substituted before starting to work on it. -- We ask you to test the code locally before merging it, and then, if - possible, write some automatic tests for the code to be run in our - Continuous Integration! Check the testing section below to know - more. -- We suggest opening a draft PR as soon as you can - so it's easier - for us to help you! - -See our [complete documentation](CONTRIBUTING.md#contributing) on the matter - -[Pull Requests](#pr) --------------------------------------- - -To improve understanding pull requests \"at a glance\" and use the power -of `auto`, we use the labels listed above. Multiple labels can be -assigned to a PR - in fact, all those that you think are relevant. We -strongly advise to keep the changes you\'re introducing with your PR -limited to your original goal. Adding to the scope of your PR little -style corrections or code refactoring here and there in the code that -you\'re already modifying is a great help, but when they become too much -(and they are not relevant to your PR) they risk complicating the nature -of the PR and the reviewing process. It is much better to open another -PR with the objective of doing such corrections! Moreover, if you\'re -tempted to assign more than one label that would trigger a release (e.g. -bug and minormod or bug and majormod, etc.), you might want to split your PR -instead. When opening a pull request, assign it at least one label. - -We encourage you to open a PR as soon as possible - even before you -finish working on them. This is useful especially to you - so that you -can receive comments and suggestions early on, rather than having to -process a lot of comments in the final review step! However, if it's an -incomplete PR, please open a **Draft PR**. That helps us process PRs by -knowing which one to have a look first - and how picky to be when doing -so. - -Reviewing PRs is a time consuming task and it can be stressful for both -the reviewer and the author. Avoiding wasting time and the need of -little fixes - such as fixing grammar mistakes and typos, styling code, -or adopting conventions - is a good start for a successful (and quick) -review. Before graduating a Draft PR to a PR ready for review, please -check that: - -- You did all you wanted to include in your PR. If at a later stage - you realize something is missing and it's not a minor thing, you - will need to open a new PR. -- If your contribution contains code or tests, you ran and passed all - of the tests locally with [pytest](#testing). -- If you're writing documentation, you built it locally with - sphinx and the format is what you intended. -- Your code is harmonious with the rest of the code - no repetitions - of any sort! - -Your code respects the [adopted Style](#styling), especially if: - -- Your code is lintered adequately and respects the [PEP8](https://www.python.org/dev/peps/pep-0008/) convention. -- Your docstrings follow the [numpydoc](https://numpydoc.readthedocs.io/en/latest/format.html) convention. -- There are no typos or grammatical mistakes and the text is fluid. - -- The code is sufficiently commented and the comments are clear. - -- Your PR title is clear enough to be meaningful when appended to the version changelog. - -- You have the correct labels. - -#### To be merged, PRs have to: - -1. Pass all the CircleCI tests, and possibly all the codecov checks. -2. Have the necessary amount of approving reviews, even if you're a - long time contributor. - - Note : You can ask one (or more) contributor to do - that review, if you think they align more with the content of your - PR. You need **one** review for documentation, tests, and small - changes, and **two** reviews for bugs, refactoring and enhancements. -3. Have at least a release-related label (or a `Skip - release` label). -4. Have a short title that clearly explains in one sentence the aim of - the PR. -5. Contain at least a unit test for your contribution, if the PR - contains code (it would be better if it contains an integration or - function test and all the breaking tests necessary). If you're not - confident about writing tests, it is possible to refer to an issue - that asks for the test to be written, or another (Draft) PR that - contains the tests required. - -As we're trying to maintain at least 90% code coverage, you're strongly -encouraged to write all of the tests necessary to keep coverage above -that threshold. If coverage drops too low, you might be asked to add -more tests and/or your PR might be rejected. See the [Automatic testing](#testing) section. - -Don't merge your own pull request! That\'s a task for the main reviewer -of your PR or the project manager. Remember that the project manager -doesn't have to be a reviewer of your PR! - -[Reviewing PRs](#reviewing) -------------- - -Reviewing PRs is an extremely important task in collaborative -development. In fact, it is probably the task that requires the most -time in the development, and it can be stressful for both the reviewer -and the author. Remember that, as a PR Reviewer, you are guaranteeing -that the changes work and integrate well with the rest of the -repository, hence **you are responsible for the quality of the -repository and its next version release**. If they don\'t integrate -well, later PR reviewers might have to ask for broader changes than -expected. - -There are many best practices to review code online, for -instance [this medium blog post](https://medium.com/an-idea/the-code-review-guide-9e793edcd683), but -here are some good rules of thumbs that we need to follow while -reviewing PRs: - -- Be **respectful** to the PR authors and be clear in what you are - asking/suggesting - remember that, like you, they are contributing - their spare time and doing their best job! - -- If there is a *Draft PR*, you can comment on its development in the - message board or making "Comment" reviews. Don't ask for changes, - and especially, **don't approve the PR** - -- If the PR graduated *from Draft to full PR*, check that it follows the - sections [Pull requests](#pr) and [Style Guide](#styling) of these - guidelines. If not, invite the author to do so before starting a - review. -- **Don't limit your review to the parts that are changed**. Look at - the entire file, see if the changes fit well in it, and see if the - changes are properly addressed everywhere in the code - in the - documentation, in the tests, and in other functions. Sometimes the - differences reported don't show the full impact of the PR in the - repository! -- If your want to make Pull Requests an educational process, invite - the author of the PR to make changes before actually doing them - yourself. Request changes via comments or in the message board or by - checking out the PR locally, making changes and then submitting a PR - to the author's branch. -- If you decide to use the suggestion tool in reviews, or to start a - PR to the branch under review, please alert the Project Manager. - Bots might automatically assign you contribution types that will - have to be removed (remember, your contribution in this case is - "Reviewer"). Instead of starting a PR to the branch under review, - think about opening a new PR with those modifications (unless they - are needed to pass tests), and alert the Main Reviewer. In any case - **don't commit directly to the branch under review**! -- If you're reviewing documentation, build it locally with [`sphinx-build`](https://www.sphinx-doc.org/en/master/man/sphinx-build.html) command. -- If you're asking for changes, **don't approve the PR**. Approve it - only after everything was sufficiently addressed. Someone else might - merge the PR in taking your word for granted. -- If you are the main reviewer, and the last reviewer required to - approve the PR, merge the PR! - -Before approving and/or merging PRs, be sure that: - -- All the tests in CircleCI/Azure pass without errors. -- Prefereably, codecov checks pass as well. If they don\'t, discuss - what to do. -- The title describes the content of the PR clearly enough to be - meaningful on its own - remember that it will appear in the version - changelog! -- The PR has the appropriate labels to trigger the appropriate version - release and update the contributors table. - -### [Main reviewer](#mainreviewer) - -At `physiopy` we use the *Assignees* section of a PR to mark the -**main reviewer** for that PR. The main reviewer is the primary person -responsible **for the quality of the repository and its next version release**, - as well as **for the behaviour of the other reviewers**. - -***The main reviewer takes care of the reviewing process of the PR, in particular:*** - -- Invites the reviewers to finish their review in a relatively - short time. - -- Checks that all elements of this document were respected, - especially the part about [Pull Requests](#pr). - -- Invites other Reviewers to respect this document, especially - the part about [reviews](#reviewing), helps them in doing - so, and checks that they do. - -- If a Reviewer keeps not respecting this document, flags them - to the project manager. - -- Decides what to do in case of a coverage decrease (in - *codecov/patch*). - -***In case of missing tests or updates to user documentation:*** - -- Asks for more documentation or tests before approving the - PR, *or* - -- Checks that the appropriate issues have been opened to - address the lack of documentation or tests (1 issue per item), *or* - -- Double-checks that the title is clear and the labels are correct to - trigger an appropriate `auto` release - feel free to change them. - -- Main reviewer **Is the one that is going to merge the PR.** - - -***After the PR has been merged and a new release has been triggered, checks that:*** - -- The documentation was updated correctly (if changed). -- The Pypi version of the repository coincides with the new release (if changed). -- New contributors or forms of contributions were correctly added in the README (if changed). - -[Style Guide](#styling) -------------------------- - -Docstrings should follow -[numpydoc](https://numpydoc.readthedocs.io/en/latest/format.html) -convention. We encourage extensive documentation. The python code itself -should follow [PEP8](https://www.python.org/dev/peps/pep-0008/) -convention whenever possible: there are continuous integration tests -checking that! You can use linters to help you write your code following -style conventions. Linters are add-ons that you can run on the written -script file. We suggest the use of **flake8** for Python 3. Many editors -(Atom, VScode, Sublimetext, \...) support addons for online lintering, -which means you'll see warnings and errors while you write the code - -check out if your does! - -Since we adopt [auto](https://intuit.github.io/auto/home.html), the PR -title will be automatically reported as part of the changelog when -updating versions. Try to describe in one (short) sentence what your PR -is about - possibly using the imperative and starting with a capital -letter. For instance, a good PR title could be: -`Implement support for files` or -`Reorder dictionary entries`, rather than ` support` or -`reorders keys`. - -[Automatic Testing](#testing) ------------------ - -`physiopy` uses Continuous Integration (CI) to make life easier. In -particular, we use the [CircleCI](https://circleci.com/) platform to run -automatic testing! **Automatic tests** are cold, robotic, emotionless, -and opinionless tests that check that the program is doing what it is -expected to. They are written by the developers and run (by CircleCI) -every time they send a Pull Request to `physiopy` repositories. They -complement the warm, human, emotional and opinionated **user tests**, as -they tell us if a piece of code is failing. CircleCI uses -[pytest](https://docs.pytest.org/en/latest/) to run the tests. The great -thing about it is that you can run it in advance on your local version -of the code! We can measure the amount of code that is tested with -[codecov](https://docs.pytest.org/en/latest/), which is an indication of -how reliable our packages are! We try to maintain a 90% code coverage, -and for this reason, PR should contain tests! The four main type of -tests we use are: - -1. Unit tests : - - Unit tests check that a minimal piece of code is doing what it - should be doing. Normally this means calling a function with - some mock parameters and checking that the output is equal to - the expected output. For example, to test a function that adds - two given numbers together (1 and 3), we would call the function - with those parameters, and check that the output is 4. - -2. Breaking tests - - Breaking tests are what you expect - they check that the program - is breaking when it should. This means calling a function with - parameters that are expected **not** to work, and check that it - raises a proper error or warning. - -3. Integration tests - - Integration tests check that the code has an expected output, - being blind to its content. This means that if the program - should output a new file, the file exists - even if it's empty. - This type of tests are normally run on real data and call the - program itself. For instance, documentation PRs should check - that the documentation page is produced! - -4. Functional tests - - If integration tests and unit tests could have babies, those - would be functional tests. In practice, this kind of tests check - that an output is produced, and *also* that it contains what it - should contain. If a function should output a new file or an - object, this test passes only if the file exists *and* it is - like we expect it to be. They are run on real or mock data, and - call the program itself or a function. - -[Recognising contributors](#recognising) ------------------------- - -We welcome and recognize [all -contributions](https://allcontributors.org/docs/en/specification) from -documentation to testing to code development. You can see a list of -current contributors in the README (kept up to date by the [all -contributors bot](https://allcontributors.org/docs/en/bot/overview)). - -**Thank you!** - -*--- Based on contributing guidelines from the [STEMMRoleModels](https://github.com/KirstieJane/STEMMRoleModels) project.* diff --git a/docs/contributors-guide/codebase/index.md b/docs/contributors-guide/codebase/index.md new file mode 100644 index 0000000..b15e957 --- /dev/null +++ b/docs/contributors-guide/codebase/index.md @@ -0,0 +1,18 @@ +## Contribution workflow + +There are many descriptions of a good contribution workflow out there. +For instance, we suggest to have a look at [tedana's workflow](https://github.com/ME-ICA/tedana/blob/master/CONTRIBUTING.md#making-a-change). +At `physiopy`, we follow a very similar workflow. The only three +differences are: + +- If you see an open issue that you would like to work on, check if it + is assigned. If it is, ask the assignee if they need help or want to + be substituted before starting to work on it. +- We ask you to test the code locally before merging it, and then, if + possible, write some automatic tests for the code to be run in our + Continuous Integration! Check the testing section below to know + more. +- We suggest opening a draft PR as soon as you can - so it's easier + for us to help you! + +You can find more in-detail description of this process in the following sections of the guide. \ No newline at end of file diff --git a/docs/contributors-guide/codebase/labels.md b/docs/contributors-guide/codebase/labels.md new file mode 100644 index 0000000..22af767 --- /dev/null +++ b/docs/contributors-guide/codebase/labels.md @@ -0,0 +1,115 @@ +## Labels + +The current list of labels are +[here](https://github.com/physiopy/phys2bids/labels). They can be used +for **Issues**, **PRs**, or both. We use +[auto](https://github.com/intuit/auto) to automate our semantic +versioning and Pypi upload, so **it's extremely important to use the +right PR labels**! + +### Issue & PR labels + +- ![Documentation](https://img.shields.io/badge/-Documentation-1D70CF?style=flat-square) Improvements or additions to documentation. This + category includes (but is not limited to) docs pages, docstrings, + and code comments. + +- ![Duplicate](https://img.shields.io/badge/-Duplicate-CFD3D7?style=flat-square) Whatever this is, it exists already! Maybe it's a closed + Issue/PR, that should be reopened. + +- ![Enhancement](https://img.shields.io/badge/-Enhancement-A2EEEF?style=flat-square) New features added or requested. This normally goes with a `minormod` label for PRs. + +- ![Outreach](https://img.shields.io/badge/-Outreach-0E8A16?style=flat-square) As part of the scientific community, we care about outreach. Check the relevant section about it, but know that this + Issue/PR contains information or tasks about abstracts, talks, + demonstrations, papers. + +- ![Paused](https://img.shields.io/badge/-Paused-F7C38C?style=flat-square) Issue or PR should not be worked on until the resolution of other issues or PRs. + +- ![released](https://img.shields.io/badge/-released-ffffff?style=flat-square) This Issue or PR has been released. + +- ![Testing](https://img.shields.io/badge/-Testing-FFB5B4?style=flat-square) This is for testing features, writing tests or producing testing code. Both user testing and CI testing! + +- ![Urgent](https://img.shields.io/badge/-Urgent-FFF200?style=flat-square) If you don't know where to start, start here! This is probably related to a milestone due soon! + +### Issue-only labels + +- ![BrainHack](https://img.shields.io/badge/-BrainHack-000000?style=flat-square) This issue is suggested for BrainHack participants! + +- ![Bug](https://img.shields.io/badge/-Bug-D73A4A?style=flat-square) Something isn't working. It either breaks the code or has an + unexpected outcome. + +- ![Community](https://img.shields.io/badge/-Community-E2C7FC?style=flat-square) This issue contains information about the `physiopy` + community (e.g. the next developer call) + +- ![Discussion](https://img.shields.io/badge/-Discussion-1C778C?style=flat-square) Discussion of a concept or implementation. These Issues + are prone to be open ad infinitum. Jump in the conversation if you + want! + +- ![Good first issue](https://img.shields.io/badge/-Good%20first%20issue-4E2A84?style=flat-square) Good for newcomers. These issues calls for a + **fairly** easy enhancement, or for a change that helps/requires + getting to know the code better. They have educational value, and + for this reason, unless urgent, experts in the topic should refrain + from closing them - but help newcomers closing them. + +- ![Hacktoberfest](https://img.shields.io/badge/-Hacktoberfest-FF7518?style=flat-square) Dedicated to the hacktoberfest event, so that people + can help and feel good about it (and show it with a T-shirt!). + **Such commits will not be recognised in the all-contributor table, + unless otherwise specified**. + +- ![Help wanted](https://img.shields.io/badge/-Help%20wanted-57DB1A?style=flat-square) Extra attention is needed here! It's a good place to have a look! + +- ![Refactoring](https://img.shields.io/badge/-Refactoring-9494FF?style=flat-square) Improve nonfunctional attributes. Which means rewriting + the code or the documentation to improve performance or just because + there's a better way to express those lines. It might create a + `majormod` PR. + +- ![Question](https://img.shields.io/badge/-Question-D876E3?style=flat-square) Further information is requested, from users to + developers. Try to respond to this! + +- ![Wontfix](https://img.shields.io/badge/-Wontfix-ffffff?style=flat-square) This will not be worked on, until further notice. + +### PR-only labels + +#### Labels for semantic release and changelogs + +- ![BugFIX](https://img.shields.io/badge/-BugFIX-D73A4A?style=flat-square) These PRs close an issue labelled `Bug`. They also increase + the semantic versioning for fixes (+0.0.1). + + - ![dependencies](https://img.shields.io/badge/-dependencies-0366D6?style=flat-square) Pull requests that update a dependency file + +- ![Documentation](https://img.shields.io/badge/-Documentation-1D70CF?style=flat-square) See above. This PR won't trigger a release, but it will be reported in the changelog. + +- ![Majormod](https://img.shields.io/badge/-Majormod-05246D?style=flat-square) These PRs call for a new major release (+1.0.0). This + means that the PR is breaking backward compatibility. + +- ![Minormod](https://img.shields.io/badge/-Minormod-05246D?style=flat-square) This PR generally closes an `Enhancement` issue. It increments the minor version (0.+1.0) + +- ![Minormod-breaking](https://img.shields.io/badge/-Minormod–breaking-05246D?style=flat-square) This label should be used during development stages (<1.0.0) only. These PRs call for a new minor release during development (0.+1.0) that **will** break backward compatibility. + +- ![Internal](https://img.shields.io/badge/-Internal-ffffff?style=flat-square) This PR contains changes to the internal API. It won't + trigger a release, but it will be reported in the changelog. + +- ![Testing](https://img.shields.io/badge/-Testing-FFB5B4?style=flat-square) See above. This PR won't trigger a release, but it will be + reported in the changelog. + +- ![Skip release](https://img.shields.io/badge/-Skip%20release-ffffff?style=flat-square) This PR will **not** trigger a release. + +- ![Release](https://img.shields.io/badge/-Release-ffffff?style=flat-square) This PR will force the trigger of a release. + +#### Other labels + +- ![Invalid](https://img.shields.io/badge/-Invalid-960018?style=flat-square): These PRs don't seem right. They actually seem so not + right that they won't be further processed. This label invalidates a + Hacktoberfest contribution. If you think this is wrong, start a + discussion in the relevant issue (or open one if missing). Reviewers + are asked to give an explanation for the use of this label. + +### Good First Issues + +Good First Issues are issues that are either very simple, or that help +the contributor get to know the programs or the languages better. We use +it to help contributors with less experience to learn and familiarise +with Git, GitHub, Python3, and physiology. We invite more expert +contributors to avoid those issues, leave them to beginners and possibly +help them out in the resolution of the issue. However, if the issue is +left unassigned or unattended for long, and it's considered important or +urgent, anyone can tackle it. \ No newline at end of file diff --git a/docs/contributors-guide/codebase/opening-issues.md b/docs/contributors-guide/codebase/opening-issues.md new file mode 100644 index 0000000..0201ba9 --- /dev/null +++ b/docs/contributors-guide/codebase/opening-issues.md @@ -0,0 +1,20 @@ +## Issues and Milestones + +At `physiopy`, we use Issues and Milestones to keep track of and +organise our workflow. **Issues** describe pieces of work that need to +be completed to move the project forwards. We try to keep them as simple +and clear as possible: an issue should describe a unitary, possibly +small piece of work (unless it's about refactoring). Don't be scared of +opening many issues at once, if it makes sense! Just check that what +you're proposing is not listed in a previous issue (open or closed) yet +(we don't like doubles). Issues get labelled. That helps the +contributors to know what they're about. Check the label list to know +what types are there, and use them accordingly! Issues can also be +**assigned**. If you want to work on an assigned issue, ask permission +first! - **Milestones** set the higher level workflow. They sketch +deadlines and important releases. Issues are assigned to these +milestones by the maintainers. If you feel that an issue should be +assigned to a specific milestone but the maintainers have not done so, +discuss it in the issue chat or in Gitter! We might have just missed it, +or we might not (yet) see how it aligns with the overall project +structure/milestone. \ No newline at end of file diff --git a/docs/contributors-guide/codebase/opening-prs.md b/docs/contributors-guide/codebase/opening-prs.md new file mode 100644 index 0000000..09e6e56 --- /dev/null +++ b/docs/contributors-guide/codebase/opening-prs.md @@ -0,0 +1,85 @@ +## Pull Requests + +To improve understanding pull requests "at a glance" and use the power +of `auto`, we use the labels listed above. Multiple labels can be +assigned to a PR - in fact, all those that you think are relevant. We +strongly advise to keep the changes you're introducing with your PR +limited to your original goal. Adding to the scope of your PR little +style corrections or code refactoring here and there in the code that +you're already modifying is a great help, but when they become too much +(and they are not relevant to your PR) they risk complicating the nature +of the PR and the reviewing process. It is much better to open another +PR with the objective of doing such corrections! Moreover, if you're +tempted to assign more than one label that would trigger a release (e.g. +bug and minormod or bug and majormod, etc.), you might want to split your PR +instead. When opening a pull request, assign it at least one label. + +We encourage you to open a PR as soon as possible - even before you +finish working on them. This is useful especially to you - so that you +can receive comments and suggestions early on, rather than having to +process a lot of comments in the final review step! However, if it's an +incomplete PR, please open a **Draft PR**. That helps us process PRs by +knowing which one to have a look first - and how picky to be when doing +so. + +Reviewing PRs is a time consuming task and it can be stressful for both +the reviewer and the author. Avoiding wasting time and the need of +little fixes - such as fixing grammar mistakes and typos, styling code, +or adopting conventions - is a good start for a successful (and quick) +review. Before graduating a Draft PR to a PR ready for review, please +check that: + +- You did all you wanted to include in your PR. If at a later stage + you realize something is missing and it's not a minor thing, you + will need to open a new PR. +- If your contribution contains code or tests, you ran and passed all + of the tests locally with [pytest](#automatic-testing). +- If you're writing documentation, you built it locally with + sphinx and the format is what you intended. +- Your code is harmonious with the rest of the code - no repetitions + of any sort! + +Your code respects the [adopted Style](#style-guide), especially if: + +- Your code is lintered adequately and respects the [PEP8](https://www.python.org/dev/peps/pep-0008/) convention. +- Your docstrings follow the [numpydoc](https://numpydoc.readthedocs.io/en/latest/format.html) convention. +- There are no typos or grammatical mistakes and the text is fluid. + +- The code is sufficiently commented and the comments are clear. + +- Your PR title is clear enough to be meaningful when appended to the version changelog. + +- You have the correct labels. + + +### Before merging + +To be merged, PRs have to: + +1. Pass all the CircleCI tests, and possibly all the codecov checks. +2. Have the necessary amount of approving reviews, even if you're a + long time contributor. + + Note : You can ask one (or more) contributor to do + that review, if you think they align more with the content of your + PR. You need **one** review for documentation, tests, and small + changes, and **two** reviews for bugs, refactoring and enhancements. +3. Have at least a release-related label (or a `Skip + release` label). +4. Have a short title that clearly explains in one sentence the aim of + the PR. +5. Contain at least a unit test for your contribution, if the PR + contains code (it would be better if it contains an integration or + function test and all the breaking tests necessary). If you're not + confident about writing tests, it is possible to refer to an issue + that asks for the test to be written, or another (Draft) PR that + contains the tests required. + +As we're trying to maintain at least 90% code coverage, you're strongly +encouraged to write all of the tests necessary to keep coverage above +that threshold. If coverage drops too low, you might be asked to add +more tests and/or your PR might be rejected. See the [Automatic testing](#automatic-testing) section. + +Don't merge your own pull request! That's a task for the main reviewer +of your PR or the project manager. Remember that the project manager +doesn't have to be a reviewer of your PR! \ No newline at end of file diff --git a/docs/contributors-guide/codebase/plug-ins.md b/docs/contributors-guide/codebase/plug-ins.md new file mode 100644 index 0000000..958ceea --- /dev/null +++ b/docs/contributors-guide/codebase/plug-ins.md @@ -0,0 +1,13 @@ +## Under development +We're still building this section of the guide, so stay tuned (or help!) + +We'd like to provide more information on some of the tools you may use in your contributions to Physiopy such as + +### Pre-commit +### CircleCI +### Pytest +### Pypi +### OSF/test data + + + diff --git a/docs/contributors-guide/codebase/reviewing-prs.md b/docs/contributors-guide/codebase/reviewing-prs.md new file mode 100644 index 0000000..af831bb --- /dev/null +++ b/docs/contributors-guide/codebase/reviewing-prs.md @@ -0,0 +1,109 @@ +## Reviewing PRs + +Reviewing PRs is an extremely important task in collaborative +development. In fact, it is probably the task that requires the most +time in the development, and it can be stressful for both the reviewer +and the author. Remember that, as a PR Reviewer, you are guaranteeing +that the changes work and integrate well with the rest of the +repository, hence **you are responsible for the quality of the +repository and its next version release**. If they don't integrate +well, later PR reviewers might have to ask for broader changes than +expected. + +There are many best practices to review code online, for +instance [this medium blog post](https://medium.com/an-idea/the-code-review-guide-9e793edcd683), but +here are some good rules of thumbs that we need to follow while +reviewing PRs: + +- Be **respectful** to the PR authors and be clear in what you are + asking/suggesting - remember that, like you, they are contributing + their spare time and doing their best job! + +- If there is a *Draft PR*, you can comment on its development in the + message board or making "Comment" reviews. Don't ask for changes, + and especially, **don't approve the PR** + +- If the PR graduated *from Draft to full PR*, check that it follows the + sections [Pull requests](#pull-requests) and [Style Guide](#style-guide) of these + guidelines. If not, invite the author to do so before starting a + review. +- **Don't limit your review to the parts that are changed**. Look at + the entire file, see if the changes fit well in it, and see if the + changes are properly addressed everywhere in the code - in the + documentation, in the tests, and in other functions. Sometimes the + differences reported don't show the full impact of the PR in the + repository! +- If your want to make Pull Requests an educational process, invite + the author of the PR to make changes before actually doing them + yourself. Request changes via comments or in the message board or by + checking out the PR locally, making changes and then submitting a PR + to the author's branch. +- If you decide to use the suggestion tool in reviews, or to start a + PR to the branch under review, please alert the Project Manager. + Bots might automatically assign you contribution types that will + have to be removed (remember, your contribution in this case is + "Reviewer"). Instead of starting a PR to the branch under review, + think about opening a new PR with those modifications (unless they + are needed to pass tests), and alert the Main Reviewer. In any case + **don't commit directly to the branch under review**! +- If you're reviewing documentation, build it locally with [`sphinx-build`](https://www.sphinx-doc.org/en/master/man/sphinx-build.html) command. +- If you're asking for changes, **don't approve the PR**. Approve it + only after everything was sufficiently addressed. Someone else might + merge the PR in taking your word for granted. +- If you are the main reviewer, and the last reviewer required to + approve the PR, merge the PR! + +Before approving and/or merging PRs, be sure that: + +- All the tests in CircleCI/Azure pass without errors. +- Prefereably, codecov checks pass as well. If they don't, discuss + what to do. +- The title describes the content of the PR clearly enough to be + meaningful on its own - remember that it will appear in the version + changelog! +- The PR has the appropriate labels to trigger the appropriate version + release and update the contributors table. + +### Main reviewer + +At `physiopy` we use the *Assignees* section of a PR to mark the +**main reviewer** for that PR. The main reviewer is the primary person +responsible **for the quality of the repository and its next version release**, + as well as **for the behaviour of the other reviewers**. + +***The main reviewer takes care of the reviewing process of the PR, in particular:*** + +- Invites the reviewers to finish their review in a relatively + short time. + +- Checks that all elements of this document were respected, + especially the part about [Pull Requests](#pull-requests). + +- Invites other Reviewers to respect this document, especially + the part about [reviews](#reviewing-prs), helps them in doing + so, and checks that they do. + +- If a Reviewer keeps not respecting this document, flags them + to the project manager. + +- Decides what to do in case of a coverage decrease (in + *codecov/patch*). + +***In case of missing tests or updates to user documentation:*** + +- Asks for more documentation or tests before approving the + PR, *or* + +- Checks that the appropriate issues have been opened to + address the lack of documentation or tests (1 issue per item), *or* + +- Double-checks that the title is clear and the labels are correct to + trigger an appropriate `auto` release - feel free to change them. + +- Main reviewer **Is the one that is going to merge the PR.** + +***After the PR has been merged and a new release has been triggered, checks that:*** + +- The documentation was updated correctly (if changed). +- The Pypi version of the repository coincides with the new release (if changed). +- New contributors or forms of contributions were correctly added in the README (if changed). \ No newline at end of file diff --git a/docs/contributors-guide/codebase/roles-permission.md b/docs/contributors-guide/codebase/roles-permission.md new file mode 100644 index 0000000..3d36cc8 --- /dev/null +++ b/docs/contributors-guide/codebase/roles-permission.md @@ -0,0 +1,4 @@ +## Under development +We're still building this section of the guide, so stay tuned (or help!) + + diff --git a/docs/contributors-guide/codebase/style-guide.md b/docs/contributors-guide/codebase/style-guide.md new file mode 100644 index 0000000..250a3ec --- /dev/null +++ b/docs/contributors-guide/codebase/style-guide.md @@ -0,0 +1,22 @@ +## Style Guide + +Docstrings should follow +[numpydoc](https://numpydoc.readthedocs.io/en/latest/format.html) +convention. We encourage extensive documentation. The python code itself +should follow [PEP8](https://www.python.org/dev/peps/pep-0008/) +convention whenever possible: there are continuous integration tests +checking that! You can use linters to help you write your code following +style conventions. Linters are add-ons that you can run on the written +script file. We suggest the use of **flake8** for Python 3. Many editors +(Atom, VScode, Sublimetext, \...) support addons for online lintering, +which means you'll see warnings and errors while you write the code - +check out if your does! + +Since we adopt [auto](https://intuit.github.io/auto/home.html), the PR +title will be automatically reported as part of the changelog when +updating versions. Try to describe in one (short) sentence what your PR +is about - possibly using the imperative and starting with a capital +letter. For instance, a good PR title could be: +`Implement support for files` or +`Reorder dictionary entries`, rather than ` support` or +`reorders keys`. diff --git a/docs/contributors-guide/codebase/tests-code-cov.md b/docs/contributors-guide/codebase/tests-code-cov.md new file mode 100644 index 0000000..10fba79 --- /dev/null +++ b/docs/contributors-guide/codebase/tests-code-cov.md @@ -0,0 +1,53 @@ + +## Automatic Testing + +`physiopy` uses Continuous Integration (CI) to make life easier. In +particular, we use the [CircleCI](https://circleci.com/) platform to run +automatic testing! **Automatic tests** are cold, robotic, emotionless, +and opinionless tests that check that the program is doing what it is +expected to. They are written by the developers and run (by CircleCI) +every time they send a Pull Request to `physiopy` repositories. They +complement the warm, human, emotional and opinionated **user tests**, as +they tell us if a piece of code is failing. CircleCI uses +[pytest](https://docs.pytest.org/en/latest/) to run the tests. The great +thing about it is that you can run it in advance on your local version +of the code! We can measure the amount of code that is tested with +[codecov](https://docs.pytest.org/en/latest/), which is an indication of +how reliable our packages are! We try to maintain a 90% code coverage, +and for this reason, PR should contain tests! The four main type of +tests we use are: + +1. Unit tests : + + Unit tests check that a minimal piece of code is doing what it + should be doing. Normally this means calling a function with + some mock parameters and checking that the output is equal to + the expected output. For example, to test a function that adds + two given numbers together (1 and 3), we would call the function + with those parameters, and check that the output is 4. + +2. Breaking tests + + Breaking tests are what you expect - they check that the program + is breaking when it should. This means calling a function with + parameters that are expected **not** to work, and check that it + raises a proper error or warning. + +3. Integration tests + + Integration tests check that the code has an expected output, + being blind to its content. This means that if the program + should output a new file, the file exists - even if it's empty. + This type of tests are normally run on real data and call the + program itself. For instance, documentation PRs should check + that the documentation page is produced! + +4. Functional tests + + If integration tests and unit tests could have babies, those + would be functional tests. In practice, this kind of tests check + that an output is produced, and *also* that it contains what it + should contain. If a function should output a new file or an + object, this test passes only if the file exists *and* it is + like we expect it to be. They are run on real or mock data, and + call the program itself or a function. \ No newline at end of file diff --git a/docs/contributors-guide/contribution-types.md b/docs/contributors-guide/contribution-types.md new file mode 100644 index 0000000..abbbcf8 --- /dev/null +++ b/docs/contributors-guide/contribution-types.md @@ -0,0 +1,74 @@ +Not sure what you'd like to contribute? You could consider... + +### Contributing with small documentation changes + +If you are new to GitHub and just have a small documentation change +recommendation (such as: typos detection, small improvements in the +content, ...), please open an issue in the relative project, and label +it with the "Documentation" label. Chances are those types of changes +are easily doable with GitHub's online editor, which means you can do +them, or ask for help from the developers! + +### Contributing with user testing + +Another, non-coding friendly way to contribute to `physiopy` is by +testing the packages. There are different kinds of tests, but to +simplify things you can think mainly about automatic tests and user +tests. To know more about **Automatic tests**, you can read the [testing +section](#automatic-testing). **User testing** are warm, human, emotional and +opinionated tests that not only check that the code is doing what it +needs to do, but also whether there's a better way to do it - namely +better reports, clearer screen outputs, warnings and exceptions, +unexpected bugs that have to be corrected. If you want to perform one, +open an issue on GitHub or drop a comment in Gitter, refer to this +[blueprint](https://docs.google.com/document/d/1b6wc7JVDs3vi-2IqGg_Ed_oWKbZ6siboAJHf55nodKo/edit?usp=sharing) +and don't be afraid to ask questions! + +### Contributing with test files + +At `physiopy` we always try to imagine and support every possible +setting out there. However, our imagination has a limit - but if you +think our packages should process a specific format/setting that you +have, we're more than glad to do so! To make it happen, we need an +example of the file we want to process, so you will have to share it +with us (and the rest of the world)! The contribution can be a full file +of data that you already acquired, a part of that file (pay attention to +what is the minimum you need to share!), or mock data. The file +contribution should come with a json file of the same name that contains +the necessary information to run `phys2bids` on that file contribution. +There is a [json blueprint in +OSF](https://mfr.de-1.osf.io/render?url=https://osf.io/jrnxv/?direct%26mode=render%26action=download%26mode=render), +you can download it and adapt it. Note that the frequency list **has to +be expressed in Hz** as an integer or float. To contribute with a test +file, open an Issue in GitHub and label it with *Test*. We'll help you +add the file in our [OSF](https://osf.io/3txqr/) space. We're extremely +grateful for this type of contribution - so grateful that we asked +allcontributors to add a dedicated category! + +### Contributing documentation through GitHub + +We use [readthedocs](https://readthedocs.org/) to create our +documentation. Every contribution is welcome and it follows the same +steps as a code contribution, explained below. + +### Contributing code through GitHub + +This section covers 90% of the contributions a project like `physiopy` +receives - code, documentation and tests. The best way to make this kind +of contribution, in a nutshell, is to: 1. Open an issue with the +intended modifications. 2. Label it, discuss it, (self-)assign it. 3. +Open a Pull Request (PR) to resolve the issue and label it. 4. Wait for +a review, discuss it or comply, repeat until ready. Issues and PR chats +are great to maintain track of the conversation on the contribution. +They are based upon GitHub-flavoured +[Markdown](https://daringfireball.net/projects/markdown). GitHub has a +helpful page on [getting started with writing and formatting Markdown on +GitHub](https://help.github.com/articles/getting-started-with-writing-and-formatting-on-github). + +### Contributing with Pull Requests Reviews + +A big challenge of software development is merging code accurately +without having to wait too much time. For this reason, Reviewers for PRs +are more than welcome! It is a task that requires some experience, but +it's very necessary! Read the [related section below](#reviewing-prs) to +start! \ No newline at end of file diff --git a/docs/contributors-guide/documentation/building.md b/docs/contributors-guide/documentation/building.md new file mode 100644 index 0000000..3d36cc8 --- /dev/null +++ b/docs/contributors-guide/documentation/building.md @@ -0,0 +1,4 @@ +## Under development +We're still building this section of the guide, so stay tuned (or help!) + + diff --git a/docs/contributors-guide/documentation/community-practices.md b/docs/contributors-guide/documentation/community-practices.md new file mode 100644 index 0000000..3d36cc8 --- /dev/null +++ b/docs/contributors-guide/documentation/community-practices.md @@ -0,0 +1,4 @@ +## Under development +We're still building this section of the guide, so stay tuned (or help!) + + diff --git a/docs/contributors-guide/documentation/index.md b/docs/contributors-guide/documentation/index.md new file mode 100644 index 0000000..3d36cc8 --- /dev/null +++ b/docs/contributors-guide/documentation/index.md @@ -0,0 +1,4 @@ +## Under development +We're still building this section of the guide, so stay tuned (or help!) + + diff --git a/docs/community/gettingstarted.md b/docs/contributors-guide/getting-started.md similarity index 83% rename from docs/community/gettingstarted.md rename to docs/contributors-guide/getting-started.md index 045a06f..3fd0282 100644 --- a/docs/community/gettingstarted.md +++ b/docs/contributors-guide/getting-started.md @@ -1,36 +1,45 @@ # Getting Started! -========================== -First of all: thank you! +First of all: thank you and welcome to the `physiopy` organisation! It's great news that you're thinking about contributing! + +Working with many people from many different places is great, but +sometimes this means that code can become messy due to the many +different ways a contribution can be made. For this reason, we have set +up some guidelines for contributions - to help you get involved ASAP! If +you lack knowledge in python development / github use / physiological +data handling, don't be scared! Try to jump in anyway. Most of the +original contributors learned these things exactly this way - jumping in +and hoping to fall in the right way without breaking too many bones. Contributions can be made in different ways, not only code! As we follow the [all-contributors](https://github.com/all-contributors/all-contributors) specification, any contribution will be recognised accordingly. -Follow these steps to get started: +## First steps + +Follow these three simple steps to get started: -1. Have a look at the [contributor guide](contributorfile.html) page as - well as the [code of conduct](conduct.html). +1. Have a look at our [code of conduct](/community/CODE_OF_CONDUCT). 2. Make sure that you have a GitHub account. You can set up a [free GitHub account](https://github.com/); here are some [instructions](https://help.github.com/articles/signing-up-for-a-new-github-account). 3. If you intend to contribute code and/or use the `physiopy` packages in any way, check that you have `git` and `pip` installed on your - system. Then install the package as a developer. This will let you + system. Then, follow the instructions below to install the package you are working on as a developer. This will let you run the program with the latest modifications, without requiring to re-install it every time. -### Note + +Linux, Mac, and Windows developer installation +---------------------------------------------- + +Note: The following instructions are provided assuming that python 3 is **not** your default version of python. If it is, you might need to use `pip` instead of `pip3`, although some OSs do adopt `pip3` anyway. If you want to check, type `python --version` in a terminal. - -Linux, Mac, and Windows developer installation ----------------------------------------------- - Be sure to have `git` and `pip` installed. Fork the phys2bids repository in GitHub, then open a terminal and run the following code to clone the forked repository and set it as your \`origin\`: @@ -119,5 +128,7 @@ working to fix it (see [here](https://docs.pytest.org/en/latest/skipping.html#xfail-mark-test-functions-as-expected-to-fail). However, if you do encounter any other error, check that you have all the extra dependencies installed and their version meets `phys2bids` -requirements. Contact us on -[gitter](https://gitter.im/physiopy/community) if you need help! +requirements. + +## Where to go next +This section needs to be added. \ No newline at end of file diff --git a/docs/contributors-guide/index.md b/docs/contributors-guide/index.md new file mode 100644 index 0000000..2ae5d22 --- /dev/null +++ b/docs/contributors-guide/index.md @@ -0,0 +1,4 @@ +## Welcome +Welcome to the Contributor Guide! We hope that this will provide you with the resources you need to interact with Physiopy's codebase and documentation. This part of Physiopy's website is currently evolving to include more information. If you'd like to get involved in suggesting or making changes to the guide, connect to our conversation [here](https://github.com/physiopy/physiopy.github.io/issues/49). + + diff --git a/docs/contributors-guide/recognition.md b/docs/contributors-guide/recognition.md new file mode 100644 index 0000000..d6875a7 --- /dev/null +++ b/docs/contributors-guide/recognition.md @@ -0,0 +1,11 @@ +### How it works +We welcome and recognize [all +contributions](https://allcontributors.org/docs/en/specification) from +documentation to testing to event organizing to code development. For each repository on Github, you can see the current list of contributors in the README (kept up to date by the [all +contributors bot](https://allcontributors.org/docs/en/bot/overview)). The type of contribution is reflected by the corresponding [emoji key](https://allcontributors.org/docs/en/emoji-key). You can also check our [Team](/community/team) for a summary of the many contributions that have been made to Physiopy as a whole. To ensure your contributions are recognized, please use Github as described in the accompanying sections of the guide! + +### Other pathways for recognition +Physiopy frequently submits posters, talks, and other projects to academic events. We typically extend authorship to all those involved in relevant development activity during the corresponding time frame. As well, we explicitly collect detailed authorship information and credentials from contributors to our [*Community Practices* documentation](https://physiopy-community-guidelines.readthedocs.io/en/latest/index.html). These kinds of recognition are usually coordinated over Slack and/or email, so be sure you are connected with us there and responsive to any relevant communications. + +### What if you believe your contribution is not being recognized? +It might take us a little while to update contributions everywhere they should be, but we want to make sure nothing is overlooked! If you have questions or concerns, contact the project manager at [physiopy.community@gmail.com](mailto:physiopy.community@gmail.com). \ No newline at end of file diff --git a/docs/index.md b/docs/index.md index 233e346..30e1d74 100644 --- a/docs/index.md +++ b/docs/index.md @@ -1,13 +1,13 @@ # Home -Welcome to the main documentation site for the physiopy community and python package! Please also check out the package's [Github Page](https://github.com/physiopy). For questions, you can always contact the project manager at [physiopy.community@gmail.com](mailto:physiopy.community@gmail.com). +Welcome to the main documentation site for the physiopy community and python packages! Please also check out our [Github Page](https://github.com/physiopy). For questions, you can always contact the project manager at [physiopy.community@gmail.com](mailto:physiopy.community@gmail.com).

## Who are we? -We are the physiopy development team consisting of an international group of volunteers. You can learn more about us by visiting the [*Community*](/community/index) page. Contributions are also very much welcomed! Check out the [*Contributors*](/community/contributor-guide) tab. +We are the physiopy development team consisting of an international group of volunteers. You can learn more about us and how to connect with us by visiting the [*Community*](/community) page. Contributions are also very much welcomed! Check out the [*Contributor Guide*](community/contributor-guide/) tab. ## What is the importance of physiological data collection and its impact on MRI? -Physiological data provides the representation of the participant with respect to extension of bodily information (i.e., heart rates, respiratory rate, skin conductance etc.). Monitoring one's physiological activity helps us understand the percerption of cognition, emotion, motivation etc. Additionaly, physiological data is a key component in understanding physiological sources of signal variance in fMRI data. Collecting these data helps to provide more accurate models of fMRI time-series. It also provides a real-time method to monitor subjects during scanning. See the [*Best Practices* section](/best-practices) for recommendations from key personnel in the field on physiological data collection and analysis. +Physiological data provides a rich representation of a research subject with respect to their bodily information (i.e., heart rate, respiratory rate and depth of breathing, skin conductance, etc.). Examining physiological activity helps us to understand the perception and embodied experience of cognition, emotion, motivation, and more. Additionaly, physiological data is a key component in understanding physiological sources of signal variance in fMRI data. Collecting these data helps to provide more accurate models of fMRI time-series. It also provides a real-time method to monitor subjects during scanning. See the [*Community Practices* documentation](https://physiopy-community-guidelines.readthedocs.io/en/latest/index.html) for recommendations from key personnel in the field on physiological data collection and analysis. diff --git a/mkdocs.yml b/mkdocs.yml index ce1b5ae..980ce83 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -2,27 +2,72 @@ site_name: Physiopy site_description: Physiopy site_author: The Physiopy developers site_url: https://physiopy.github.io +repo_url: https://github.com/physiopy/physiopy.github.io +repo_name: physiopy/physiopy.github.io # Copyright copyright: Copyright © 2020-2024, The Physiopy Community +# Set up theme with Material for Mkdocs +theme: + name: material + favicon: assets/images/favicon.png + logo: assets/images/logo.png + icon: + repo: fontawesome/brands/github + features: + - navigation.tabs + - navigation.indexes + - navigation.sections + palette: + # Palette toggle for light mode + - scheme: default + toggle: + icon: material/brightness-7 + name: Switch to dark mode + + # Palette toggle for dark mode + - scheme: slate + toggle: + icon: material/brightness-4 + name: Switch to light mode + +# Content of the website nav: - Home: index.md - Libraries: - - Libraries: libraries.md - phys2bids: libraries/phys2bids.md - phys2denoise: libraries/phys2denoise.md - peakdet: libraries/peakdet.md - - Community Practices: https://physiopy-community-guidelines.readthedocs.io/en/latest/index.html + - Contributor Guide: + - Welcome: contributors-guide/index.md + - Recognizing contributions: contributors-guide/recognition.md + - Getting started: contributors-guide/getting-started.md + - Types of contribution: contributors-guide/contribution-types.md + - Contributing to the codebase: + - Digging into the code: contributors-guide/codebase/index.md + - Opening issues: contributors-guide/codebase/opening-issues.md + - Opening PRs: contributors-guide/codebase/opening-prs.md + - Reviewing PRs: contributors-guide/codebase/reviewing-prs.md + - Testing and code coverage: contributors-guide/codebase/tests-code-cov.md + - Roles and permissions: contributors-guide/codebase/roles-permission.md + - Style guide: contributors-guide/codebase/style-guide.md + - Labels: contributors-guide/codebase/labels.md + - Under the hood: contributors-guide/codebase/plug-ins.md + - Contributing to the documentation: + - Welcome: contributors-guide/documentation/index.md + - Building documentation: contributors-guide/documentation/building.md + - Adding to Community Practices: contributors-guide/documentation/community-practices.md + - Community Practices: + - Community Practices: https://physiopy-community-guidelines.readthedocs.io/en/latest/index.html - Community: - Welcome: community/index.md - - Getting Started: community/gettingstarted.md - - Contributor Guide: community/contributor-guide.md - Open Datasets: community/open_datasets.md - Other Tools: community/other_tools.md - Code of Conduct: community/CODE_OF_CONDUCT.md - Team: community/team.md - - OHBM 2023 Tutorials: ohbm23_tutorials.md + - Tutorials: + - OHBM 2023 Tutorials: ohbm23_tutorials.md