Hi Folks,
Some of you, who regularly visit the TW GitHub Repo will probably have seen, that the issues page and the pull request page are much more colourful now.
All the currently open issues have labels now. Those labels can be assigned manually by the repo maintainers. They should help us (the community) to easily sort / filter issues, to find out how to contribute.
Background
Some weeks ago @jeremyruston and I did sit down and discussed “the naming” and “the meaning” of those labels.
In the following weeks – till now – I did read and label all of the existing issues and most PRs.
Starting with 1100+ open issues and 200+ pending PRs.
Jeremy was able to merge some of the valid pull requests. Some PRs had to be closed, because they where implemented in a different way. Almost halve of the pending PRs are work-in-progress aka draft at the moment.
I was able to resolve quite a view of the pending issues. So we are down to 880 now and all of them are labelled.
Starting Point for Contributors
-
Issues labelled documentation are good starting points for contributors which are “cool” with TW wikitext
- Knowing the Documentation Style Guide and
- Using edit.tiddlywiki.com is the fastest way to get going with documentation improvements
-
Issues marked actionable and basic are good starting points for new contributors, who can help with HTML, CSS and JavaScript code
Important
- Basic complexity does not mean trivial. It means “low risk” to cause backwards compatibility problems
- If you want to start a new PR for an issue, make sure it has an actionable label
How to get an actionable label
Pull requests have a higher chance to be merged, if the related issues is actionable.
If an issue has no actionable label yet, but you are interested to help, or you are interested in the “feature”, you will need to kick of or restart the discussion again.
Label explanation
The following list is alphabetically sorted.
There is a GH issue: [TEST] all labels - and describe them · Issue #9399 · TiddlyWiki/TiddlyWiki5 · GitHub that has all labels assigned, so it will show up in every filter. It contains the same info that will follow here, as a reference. The text in the GH issue is the “source of truth”.
actionable
That’s the goal!
- Issues with the actionable label, should be possible to create a PR
- Discussion that came to an actionable conclusion
- If Jeremy or an other maintainer explicitly asks for a PR
- If possible maintainers give it a “basic” or “advanced” label
actionable:code
- Same as actionable
- This issue also contains some (tested) code snippets, that may help contributors to work with
- Especially issues created by Eric Shulman work that way
advanced
- Advanced complexity
- Risk of compatibility problems
basic
- Basic complexity
- Low risk of backwards compatibility problems
bug
We want to get rid of them 
-
Issue, that can be replicated, can be considered a bug eg:
- Performance regression
- Functionality regression
- RSOD
- Has to be acknowledged as a bug by a maintainer
- Bugs should get high priority - Help / PRs are very welcome
compatibility
- Most likely breaks backwards compatibility
- Considered advanced difficulty
- PRs marked with “compatibility” label will require patience from the contributor
- May “move” in a frustratingly low pace – but from time to time we will need them
discussion
- If the OP (original post) is not actionable yet – and
- There are 5-10 posts argumenting back and forth, the issue is considered a discussion
- If a discussion also has an actionable label, it should be possible to create a PR
- A discussion can be about an improvement, newfeature, refactor – If it gets an actionable label
- If there is a long discussion, it can be considered “advanced” complexity
documentation
- Issues labelled docs are good starting points for new contributors.
- There are TW documentation guidelines
- Improving docs is considered “basic” difficulty
- Documentation issues are considered “actionable”
- Especially if done with https://edit.tiddlywiki.com
improvement
- Existing functionality, that can / should be improved
- Considered “basic” or “medium” complexity
- Improvements should not trigger a compatibility label
- If they do, they should be labelled “refactor” instead (improvement is removed)
native:app
- These issues discuss problems with 3rd party native apps, which may also need some work to be done with TW
needswork
- Issue that is not actionable at the moment
- Feedback from the issue creator is needed
- PR that needs more work to be merged.
- Eg: Merge conflicts need to be resolved.
newfeature
- New functionality that does not exist at the moment
- Considered “basic” to “advanced” complexity
- Can have “compatibility” label
pluginise
- Functionality, that should be part of a plugin
- core plugin or
- 3rd party plugin
refactor
- Usually, quite some work has to be invested
- Is considered advanced complexity
- Needs to take backwards compatibility into account from the beginning
- Can be slow
usability
- Issues that may change or improve the user workflow
- Used mainly in combination with issues labelled “discussion” and “improvement”
usability:a11y (accessibility)
- Issues that may improve accessibility for users using assistive tools
- Also see: usability
admin-review
- Admin marker for issues that should be reviewed again
- needs a new label
- has no label yet
Information here will be updated in the future. But for the start – that’s it.
Have fun!
Mario
