Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>

[[ 🗃 ^yEzqv rel4tion-wiki ]] :: [📥 Inbox] [📤 Outbox] [🐤 Followers] [🤝 Collaborators] [🛠 Commits]

Clone

HTTPS: git clone https://vervis.peers.community/repos/yEzqv

SSH: git clone USERNAME@vervis.peers.community:yEzqv

Branches

Tags

master :: people / fr33domlover /

wiki-organization.mdwn

This wiki is getting big. And big means complexity and more difficult management. I’d like to discuss some issues which arose lately, and find solution. Make some decisions. Write some guidelines which explain how to organize the content and where to put new things.

Kinds of content:

Kinds of projects:

Ways to merge content types:

Here is an idea: I can choose by philosophy. When separating info and design, it makes the wiki work in a client-server mode. End users see just the pretty info and are separated from the hard work done in the design section. But when putting them under the same title, it works in a collaborative shared manner: Everyone can read the info and make changes and designs at the same time.

DECISION: I’m mixing them together.

One thing this decision causes is that the actual work spreads over the whole wiki. Some of it is under [[Components]], some it under [[Tools]] and some may be under some other documentation sections. Any page may contain incomplete information or open tasks. In order to help people find open tasks and incomplete designs and code, there must be some “road sign” page which points to these places.

I considered creating a Projects page, but at the moment the content is organized reasonably well, after the last changes I made. All the work is under [[Components]] and under [[Tools]]. Also, [[work-in-progress]] gives a nice overview.

Idea: Use colors, tags and/or progress bars to indicate the completion status of each project. Hmmm… may be cool and visually appealing and everything, but it also means extra maintenance or those progress marks. I’ll use them if I ever feel I really need them. I remember I did once, while working on a document probably not yet imported into this wiki.

[[TODO|TODO/OPEN]] organize ISP/CHISP project and /tools and /tools/systems etc., consider reorganizing the whole top-level, maybe separate implementation plans from user docs (e.g. /tools can have user docs but plans are under /projects or /components). Instead I can have “project pages” which have both user docs and development materials. Think what GNOME does: they have gnome.org, developer.gnome.org, wiki.gnome.org

[See repo JSON]