# Feedback for RSECon24 workshop: Effortlessly creating Python packages with good practices

This document: https://tinyurl.com/rsecon24pt

:::info
:bulb: Please add your your answer or comment to the relevant section below
:::

## What features did you like the most?

- Thanks very much for the introduction - I've not seen `copier` before! This is a difficult type of session to run a workshop for and I wanted to say I thought the delivery of the material was very clear and effective from both trainers!
- compared to cookiecutter, it seems more modular and easily applicable for the whole life of the package
- Nice to see a template created specifically for research software - the default templates in my experience needs an awful lot of editing so it's very useful to have this! Thanks for a useful session.
- I liked the "minimum" option as a pragmatic solution for getting users to select at least some best-practices, without forcing them to look at all the features.
- I like the option to choose which tools/best practices to add as some researchers are not ready for the full set, but good to give them the minimum tool and show them how to update later when they are ready
- It's good to have all these things in one place, with the items relevant to scientific software included.
- ..
-
## What features need to be improved?

- The boiler plate that meets best practice
- Instructions for set up for session were not up to date - instructed to create an uneccessary conda file
- The instructions are maybe a bit outdated
- More documentation on the different options, how would a researcher decide what to use? The examples are useful though
- ..
- ..
- ..
-

## What features would you like to be added?

- Example feature.
- mkdocs in addition to sphinx - much more straightforward and uses markdown instead of rst (works tidier with GitHub) (+1 vote)
- Options for customising the tooling (linters, type checkers, packaging tool options) (+2 vote)
- More detailed instructions for using/importing the package (or links to such instructions)
- Choice of build backends (or justification of why not)
- ..
- ..
-

## Any other suggestions or notes?

- Is is possible to add the intial GitHub issues via the GitHub API?
- Maybe useful to have some prereading/prerequesites for Python package/github experience! Some confusion in the room not because of a lack of clarity in delivering, but because people did not know what a package was
- Ability to specify the name of the GitHub repo which is used by links in the README etc (for when this differs from the name of the python package)
- Another option with more features is https://github.com/scientific-python/cookie - what is the overlap in these templates?
- Some of the features here seem to overlap with those offered by "poetry" but I don't think this template is compatible with poetry so users have to choose to use one or the other. Would it be possible to make this a poetry plugin, so that we can have the best of both, and avoid the need to re-implement base features in both the systems?
- Have you considered using `hatch` as a build system, rather than `setuptools`?

## Do you want to get involved in hackatons, code reviews, sprints?

- Example: Yes, I would like to do code reviews.
- Affiliation: Somewhere in universe
- email: [e-mail] github: @me

- Collaborate on the template / compare tooling choices
- Adrian D'Alessandro
- Imperial College London
- [e-mail]
- Our template: https://github.com/ImperialCollegeLondon/python-template
- ..
- ..
- ..
-