Goals
This project stores, organizes and develops tasks and ideas for the Splitcells Network.
Details
This is done via JavaDoc (in order to easily support automatic refactoring) or CommonMark. The project Identity Generator on Codeberg is used in order to generate unique issue ids.
Overview And Status
Standard Projects
Projects that are being worked cyclically, and probably will never be finished.
- Accessibility: Improve accessibility:
- Description: We want to use the software, guys. RIGHT?! Right? right? ... ehh
- Review advertisement, introductions and info linked by README, because that is the primary material for newcomers.
- Link
- Compatibility, portability and adaptability:
- Description: Make code easy portable, translatable and adaptable to other languages and environments.
- Link
- Cooperation and symbiosis:
- Description: Tit for tat
- Link
- Documentation project:
- Description: Nobody reads this xD
- Link
- Features:
- Description: To the moon!
- Link
- Maintenance project:
- Description: Improve quality and fix bugs.
- Link
- Deployment project
- Description: Administer deployments
- Link
- Performance Engineering
- Description: We have a need for speed.
- Link
- Webserver Development
- Description: Organizing and presenting data is the foundation of a good day
- Link
- Developer Support
- Description: Your issues need images? Here is the place for that, but only for developers of this project and not users.
- Host Link
- Major Projects
- Description: This is an archive of readable descriptions of some major projects, that can be used as advertisement for specific groups.
- Link
- Community Guidelines
- Description: We comment on guidelines.
- Link
- Blog
- Description: Speaking to the void about the development process.
- Link
Notes
- This is a ticket system in the form of a blog. Previously, Hugo was used, but Hugo requires a special subset of CommonMark format. A simplified and therefore easily portable folder structure is preferred. Most notably, links between documents cannot be correct in the source code and in the rendered website.
- Generally speaking all tickets should be reachable via this blog.
- This blog is only used for complex or important tickets, that may create lasting requirements. It may also be used for tickets, were its reasoning is important or complex and therefore needs to be documented, but does not make sense to be placed inside the source code repo. Other tickets are linked from this blog.
- A dedicated Git repo is used in order to avoid problems caused by polluting other repos. As this repo is about any ticket related to network projects, this also avoids commits to other Git repos, which contains tickets unrelated to the other Git repos.
- Git-bug is not used, because it is not possible to read and edit its content via git and text editors. Instead, the program git-bug itself is required. Git-bug could be used in the future in order to mirror tickets to another platform.
- Migrate inactive tickets into a source code repository, so that each one acts as trigger at one fitting position. In other words, those inactive tickets get relevant, when the corresponding source code is being worked on. Alternatively, put such issues in the JavaDoc of this repo, as this Java project can link to any source code thing in the Splitcells projects. This way the source code repos are not bloated with comments and tasks.
- Use only project construct on hosters like Codeberg or GitHub, if there is a current need for that (i.e. issues on those hosts support image attachments or it is useful for other users.).
Format for Tasks
# Weekly deploy static website.
* Issue number: [\#...](link to issue, that defines the number)
# Task Description
# Service
[This is a list of tasks, that are executed cyclicly.]
# Tasks
[Open and Closed Tasks]
* [ ] Task to be done.
* [x] Completed task. -> Conclusion
* [o] Task not to be done, as it was rejected. Such a task may not be deleted for documentation purposes.
Things like `* [o]` can create some rendering issues, where renderers do not support different item types in a list,
but this will be always a problem.
Furtheremore, the not supported rendering of check boxes still looks mostly ok.
Using `[o]` has the benefit, that one does not need to note on all such tasks explicitly, that they were not done.
-> Optional Reason for rejection.
# Completed Tasks
[Tasks that are done and stored for documentation purposes.
This is optional, so that one can easily see only the open tasks.]
# Ideas
[List followup tasks to this ticket here.]