update contributing guide

[clewis7]

closes #196

Inspiration from plenoptic contributing guide

Major updates to the contributing guide walking users through how to contribute to nemos including:

• development cycle
• adding new tests
• adding documentation
• adding specific features (regularizer, solver method, model, basis)

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 98.09886% with 5 lines in your changes missing coverage. Please review.

Project coverage is 97.22%. Comparing base (23433ce) to head (7430340).
Report is 130 commits behind head on development.

Files	Patch %	Lines
src/nemos/base_regressor.py	96.35%	5 Missing ⚠️

Additional details and impacted files

@@               Coverage Diff               @@
##           development     #198      +/-   ##
===============================================
- Coverage        97.23%   97.22%   -0.02%     
===============================================
  Files               15       18       +3     
  Lines             1484     1622     +138     
===============================================
+ Hits              1443     1577     +134     
- Misses              41       45       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[clewis7]

@BalzaniEdoardo made some progress on the contributing guide, left the section on adding a new optimizer and basis empty...I'm not as familiar with how those should look

happy to update or add anything you think is missing :D

[BalzaniEdoardo]

wow, great, I added some comments on what you did. I am going to tackle the sections that are missing

[BalzaniEdoardo]

what's your opinion of using:
git add -u .

for adding any updated file?

[clewis7]

My only thought is that sometimes there are files that we don't want people to commit. For example, I often test things in a juypter notebook but I would never want to commit that. I think it is better to have people do git status and then selectively choose the correct files.

[BalzaniEdoardo]

are the notebook are part of the repo?

[billbrod]

I agree it's a bad idea to tell people to use git add . (though I wasn't aware of -u, that's a handy flag, and avoids many of the potential problems). but I agree with Caitlin that we want people to be selective in what they add

[billbrod]

This looks really good Caitlin, thanks for putting in the work! I've got some notes, both here and scattered throughout.

• Curious about the changes to the workflow files in .github, what's going on there?
• you used **_NOTE_** in several places. I only remarked on it once or twice, but I think there is a supported admonition-like syntax that is probably more what you want here
• Small note, and I know I'm guilty of this too (because I use emacs), but we should probably come up with guidance on line wraps in markdown files / blocks. they're inconsistent here (and I know Edoardo and I have done it differently in the past). Should we use line wraps for a single paragraph? if so, what line length? or should every paragraph be a single line?
• You might want to describe releases: what system do we use for coming with version labels, what must be done to create a release

[BalzaniEdoardo]

This looks really good Caitlin, thanks for putting in the work! I've got some notes, both here and scattered throughout.

* Curious about the changes to the workflow files in .github, what's going on there?

This prevent triggering the ci on drafts

* you used `**_NOTE_**` in several places. I only remarked on it once or twice, but I think there is a supported [admonition-like syntax](https://github.com/orgs/community/discussions/16925) that is probably more what you want here

fixed

* Small note, and I know I'm guilty of this too (because I use emacs), but we should probably come up with guidance on line wraps in markdown files / blocks. they're inconsistent here (and I know Edoardo and I have done it differently in the past). Should we use line wraps for a single paragraph? if so, what line length? or should every paragraph be a single line?

I don't have a big opinion on that, up to you

* You might want to describe releases: what system do we use for coming with version labels, what must be done to create a release

@billbrod can you add some text on that, I think you are the only one that actually played around with "setuptools-scm"?

[BalzaniEdoardo]

Suggested change

	> **_NOTE:_** Below we are checking out the `development` branch. In terms of the `nemos` contribution workflow cycle, the `development` branch accumulates a series of
	> [!NOTE] Below we are checking out the `development` branch. In terms of the `nemos` contribution workflow cycle, the `development` branch accumulates a series of

[billbrod]

This looks good to me! Just two small additions I'd like to see:

• I think we should describe tox in CONTRIBUTING somewhere, even if we don't recommend people generally use it. The main reason is because tox is what happens in the test, so it's what people need to make sure passes, and we can link to the tox.ini file to show all the commands that are run (whereas this file will likely fall out of date if we change the commands)
• For the schematic in 06-glm.md:
  • we currently have both png and svg versions of the file, but only the png is used. why are both here?
  • is this created manually or scripted? if it's scripted, I think we should just include the script here and run it during the docs build. that will be easier to keep in sync with future changes.

Note that I also pushed some changes myself, double-check whether they all look good to you.

[BalzaniEdoardo]

This looks good to me! Just two small additions I'd like to see:

* I think we should describe tox in CONTRIBUTING somewhere, even if we don't recommend people generally use it. The main reason is because tox is what happens in the test, so it's what people need to make sure passes, and we can link to the `tox.ini` file to show all the commands that are run (whereas this file will likely fall out of date if we change the commands)

I'll add a paragraph about this

* For the schematic in `06-glm.md`:
  
  * we currently have both png and svg versions of the file, but only the png is used. why are both here?
  * is this created manually or scripted? if it's scripted, I think we should just include the script here and run it during the docs build. that will be easier to keep in sync with future changes.

The svg is create by pyreverse but the arrows and boxes placement is not well organized, so i edited it manually. I am keeping the svg around if I'll need more manual edits. If it is not to heavy I would keep it

Note that I also pushed some changes myself, double-check whether they all look good to you.

[billbrod]

Just the wording changes I proposed, and then this looks goodt o me!