Future of documents

Hey!

there is this event this afternoon - about documentation of commons, and it’s been sometimes at IndieHost we think about it, and so we wanted to discuss about it here.

First look at this image from this website, and then, look at these documents:

Check these 3 bullets, feel free to edit the document directly, or comment here about specific parts.

1 Like

You may wish to link to this website https://iilab.github.io/contentascode/ and not to this image https://talk.libreho.st/uploads/short-url/gdk3zMZZpLR0dLRS8lsuokzDEwg.png in your first link.

I like how https://www.fiduswriter.com/ integrates real-time and track changes workflows, like Google Docs does. You can help me running our own instance in :slight_smile:

This is not the Content as Code workflow as developed with iilab, but shows an environment usable today.

Your pad is a great starting point for defining further requirements. And thanks for including TransforMap :wink:

1 Like

This was a typo, it is now corrected.

Hehe, I’ve been checking everything lately, and I already stumbled upon this one :slight_smile: especially because of the template feature.
But actually, I realized that @unteem already did the job here:
https://www.lamyne.org/admin with netlify CMS, it is really good, I really like it :wink:

We are actually thinking, on how to integrate all these things together.
What is a person, what is a group, what is an event, what is a document. To help end user, we need these things to be unic, and synced among the different tools (Nextcloud, chat, forum, oIdP, website, kanban, gitlab…)

We start to have a nice vision/idea, we have to start the requirements phase, and then the mockups :wink:

1 Like

This sounds very much like you want to apply DDD methodology, before starting the development.

DDD references

Summaries from DDD – blog.opus.ch

Assessment First

  1. Draw a context map. Can you draw a consistent one, or are there ambiguous situations?
  2. Attend to the use of language on the project. Is there a Ubiquitous Language? Is it rich enough to help development?
  3. Understand what is important. Is the core domain identified? Is there a domain vision statement? Can you write one?
  4. Does the technology of the project work for or against a model-driven design?
  5. Do the developers on the team have the necessary technical skills?
  6. Are the developers knowledgable about the domain? Are they interested in the domain?

Essentials for strategic decision making

  1. Decisions must reach the entire team. Otherwise, people that don’t know will undermine it.
  2. The decision process must absorb feedback. Imposing decisions on teams without considering feedback cannot be successful.
  3. The plan must allow for evolution. Embrace an agile mindset regarding your decisions and validate them regularly.
  4. Architecture teams must not siphon off all the best and brightest
  5. Strategic design requires minimalism and humility. Less seems to be more regarding design decisions.
  6. Objects are specialists; developers are generalists. Most developers are keen to not only write code but also influence the design.

What do you mean by this? Are these eventually bounded contexts in DDD terminology, and might help us build a ubiquituous language with them, altogether represented in a context map?


I’d be happy to continue formulating the domain vision based on your preliminary work with iilab, eventually leading to PRs to or a fork of https://iilab.github.io/contentascode/. Is it worth updating or maintaining in some parts?

To arrive there, I’d like to know a little more about the documents in.

For now they appear to be a collection of user stories to me, which roughly share the threefold form problems (requirements), solutions and examples.

In which process do you think could we turn these functional requirements into technical ones, to allow for assessing actual implementation vectors?