Expand contributing guide with specific style guidelines

[K-Meech]

Closes #296

This PR expands the contributing guide, adding sections for general / this lesson as suggested by @tobyhodges on the contributing guide issue. I copied over relevant content from the collaborative lesson dev contributing guide which was linked on the issue. I also added specific style suggestions based on various closed issues/PRs from this repository.

[github-actions]

Thank you!

Thank you for your pull request 😃

🤖 This automated message can help you check the rendered files in your submission for clarity. If you have any questions, please feel free to open an issue in {sandpaper}.

If you have files that automatically render output (e.g. R Markdown), then you should check for the following:

• 🎯 correct output
• 🖼️ correct figures
• ❓ new warnings
• ‼️ new errors

Rendered Changes

🔍 Inspect the changes: https://github.com/datacarpentry/image-processing/compare/md-outputs..md-outputs-PR-345

The following changes were observed in the rendered markdown documents:

What does this mean?

If you have source files that require output and figures to be generated (e.g. R Markdown), then it is important to make sure the generated figures and output are reproducible.

This output provides a way for you to inspect the output in a diff-friendly manner so that it's easy to see the changes that occur due to new software versions or randomisation.

⏱️ Updated at 2025-06-15 14:23:47 +0000

[tobyhodges]

This looks great to me, thanks so much @K-Meech. Excited to see what the other lesson Maintainers think.

[marcodallavecchia]

This looks great @K-Meech! Thanks a lot! I just left a small comment regarding the Python vs any code for the source code of a potential contribution.

[marcodallavecchia]

Should we keep it general for any programming language? Is there a specific reason for which we would reject a contribution of an image created with Matlab code or ImageJ macro?

[mkcor]

I don't think we should reject it, but perhaps we don't want to encourage it? 😜

For example, is it straightforward to document the equivalent of

image-processing/episodes/fig/source/06-blurring/create_blur_animation.py

Lines 11 to 21 in 3982f8c

	### USAGE
	# The script was written in Python 3.12 and required the following Python packages:
	# - numpy==2.2.3
	# - scipy==1.15.2
	# - matplotlib==3.10.1
	# - tqdm==4.67.1
	#
	# The script can be executed with
	# $ python create_blur_animation.py
	# The output animation will be saved directly in the fig folder where the markdown lesson file will pick it up
	###

for an ImageJ macro?

[mkcor]

I don't think we should reject it, but perhaps we don't want to encourage it? 😜

For example, is it straightforward to document the equivalent of

image-processing/episodes/fig/source/06-blurring/create_blur_animation.py

Lines 11 to 21 in 3982f8c

	### USAGE
	# The script was written in Python 3.12 and required the following Python packages:
	# - numpy==2.2.3
	# - scipy==1.15.2
	# - matplotlib==3.10.1
	# - tqdm==4.67.1
	#
	# The script can be executed with
	# $ python create_blur_animation.py
	# The output animation will be saved directly in the fig folder where the markdown lesson file will pick it up
	###

for an ImageJ macro?

[uschille]

Thanks @K-Meech, this is great! I second the minor amendments proposed.

[K-Meech]

Thanks all for the input! I've now updated the text with all the suggested changes. Could someone take a final look through - and check all looks good?

@marcodallavecchia - good point about the image/figure source code. For now, I've left the comment as Python only - mainly in the interest of ease of maintenance. As this lesson focuses on Python, it's likely that not all maintainers (or future maintainers!) will be familiar with ImageJ macro (for example), which could make modifying / updating this source code difficult. Very happy to re-visit this though, if a non-python figure is added in the future + if anyone else has a different opinion on this 😄