# Package Splits and Closures

We will disambiguate between packages which are too large in scope and those which are too small (data only / scripts) and use these rules as **a guideline** for handling issues.

Note that these are subject to interpretation and each issue should be handled separately.

## Splitting
For meta-packages; or projects which have multiple components, the following guidelines are suggested:
- Focus on the minimal set of packages described to run the **installation instructions**
- Where there are **more than 3 packages** required to reach a first output
- Assign more mentees (no more than 3)

The idea is to have the mentees work on as many distinct projects which can be used to form `flakes`.

- It is possible that one mentee may wish to spend time exclusively on one project throughout the SoN
- In this situation, as long as there are at least 3 distinct parts to the project, it should be split and considered for completion

The only issue with this is that we may package less than the required number of **NGI projects**.

### Open Questions
- What constitutes substantial effort? (how to decide when to split)
- Scripts can be converted to `flakes`
- Websites can provide `devShell` flakes
- Can split packages be considered as part of the completion metrics or will we need to close are replenish with NGI projects to hit the 3x criteria
## Closure
The following shall be criteria for closure:
- Data only repositories
- Non-standard spec implementations (??)

For every closure, we can replenish the issue list with another NGI project.
### Open Questions
- Some projects have 3rd party spec implementations. Are these supported?