Skip to content

www-splitcells-net/net.splitcells.network.community

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Splitcells Network Community

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.

  • 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
  • Deployment project
    • Description: Administer deployments
    • 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
  • Documentation project:
    • Description: Nobody reads this xD
    • Link
  • Features:
    • Description: To the moon!
    • Link
  • Maintenance project:
    • Description: Improve quality and fix bugs.
    • Link
  • Webserver Development
    • Description: Organizing and presenting data is the foundation of a good day
    • Link
  • The Symbiosis Project

Very Low Priority Standard Projects

  • Accessibility and Design: 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
  • Blog
    • Description: Speaking to the void about the development process.
    • Link
  • Community Guidelines
    • Description: We comment on guidelines and things happening.
    • 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
  • Performance Engineering
    • Description: We have a need for speed.
    • Link
  • Security
    • Description: What could go possibly wrong?
    • Link

Notes

  • In order to mark tasks in task-archives with a high priority, add 9999- as the file name prefix. Do this with at most 1 task, as otherwise there will be a creep towards many such tasks. Change the documents date in its file name back to its original, when the task is started.
  • very low priority means, that the related thing is currently not being worked on, on a regular basis. So, it is also highly likely, that the related project is not up to date. In other words, there is no person regularly working on the related thing.
  • 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

  • The file name format is [YYYY-MM-DD|daily|weekly|...]-t[ticket number]-[ticket name].md. The ticket number is placed in the file name, because it is faster to look up the ticket number that way, than to look into the file. Often, the file is already opened as it is being worked on, but viewed in a way, that the ticket number is not visible. This causes a significant amount of scrolling.
  • The Start Date: YYYY-MM-DD, End Date: YYYY-MM-DD and date in the filename are interpreted in the notification parser of the website server, in order show these in the notification queue. See https://splitcells.net/net/splitcells/website/notifications.html such a queue.
  • File content format:
# Weekly deploy static website.

* Issue number: [\#51](link to issue, that defines the number)
* Start Date: 2025-04-05
* End Date: 2025-04-06

# Task Description
# Service Tasks
[This is a list of tasks, that are executed cyclicly.]
# Acceptance Note
[States how the project ended.]
# 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.

# Done 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.
 Mark these tasks as done, when tasks are made based on these ideas.
 Mark such tasks as rejected, when tasks are not made based on these ideas.]

Considerations

Rename net.splitcells.network.community to net.splitcells.community as this is a community project for the Splitcells project and not just the Splitcells Network project.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages