Just +1 agree on this and looking forward to a flow of RFC documents
on Devuan infra to be debated avoiding universal statements as "cannot
be written in X language" of sorts. Our current priority is distribute
responsibilities and recognise specialization and competence.

Daniel please stop obstructing work being done with reviews until a
documentation is submitted and please regard the setup of the server
you are assigned as the highest priority since that is a blocker to
involvement right now!


ciao




On Tue, 25 Jul 2017, Evilham wrote:

> Just wanted to add a little something:
>
> Am 25/07/2017 um 13:30 schrieb Daniel Reurich:
> > We don't need a hefty design document! We need to know what the
> > problems are you're trying to solve??
>
> Yes we do. Documentation is paramount, documentation allows for workload
> and knowledge distribution, it empowers people who are willing to help.
>
> Right now, Devuan development and functioning depends heavily on _a lot_
> of implicit knowledge, which can be quite frustrating for newcomers (hi!).
>
> At current scale it kinda works, but it can get out of hand very quickly.
>
> Documentation should, overall, be concise and good structured, allowing
> for a good overview of the whole as well as, when needed, for a good
> understanding of the separate components.
>
> This topic has been discussed a couple times in the weekly meetings and
> one of the ideas involved starting articles on the friendsofdevuan wiki
> to encourage user-editing and content creation; I would think it's a
> good idea to extend that spirit to developer and infrastructure
> documentation.
>
> Yes, not everyone has or should have access to the infrastructure, but
> everyone should be able to know how it works; anything else is putting
> all eggs in a couple baskets and that's not good for the long-term
> sustainability of the project.
>
> When I'm out of my crazy July, I'll come back to this and see what I can
> do / discuss what can be done documentation and packaging-wise.