Wiki: Initial topics + points to cover about cips HOT 5 OPEN

I would think that quite a bit of this is a good fit for a CONTRIBUTING document in the repository? All the parts that talk about the workflow of how CIPs are produced, reviewed, and accepted?

from cips.

A wiki and a contributing guide may be differentiated by the level of emotional engagement the reader has with the project . A person opening a contributing guide has a at least semi-conscious desire to contribute to the project which implies some level of emotional ownership. A wiki is more suited to people who are curious but not necessarily committed to doing something - driven by curiosity they are just exploring.

This difference becomes more or less important based on who is involved, or more precisely - on how you define your community. If the community is defined by individual human beings a wiki is a must have, since its better to rely on open initiative and avoid asking people to provide any inputs even if so indirectly as the need to open a contributing.md to access some crucial information like the comms channels, the workflow, etc.

Noticing dissatisfaction among some community members and reflecting on reasons and ways to mitigate in the future. The contributing guides I found tend to focus on technical aspects but miss out on the human engagement part, so I wrote a guide with its target audience being an unaffiliated developer who is interested in joining a working group. The guide aims to promote transparency and reflection in the reader, and the goals are to promote clarity of intent and prevent burnout among contributors. I hope it is insightful.

from cips.

Another nice-to-have page on the wiki - a list of the top 10 most widely used/impactful CIPs.
Could act as a nice starting place for people to catch up on the key knowledge.

from cips.

Wikis are notoriously hard to organize on Github, as there's no good way to arrange the sidebar of links (GitHub sorts them lexicographically which is often .. not the best way to organize the content).

Having said that, with a properly maintained "homepage" they can be bearable. I see wiki as good ways to record decisions or keep track of a logbook (e.g. https://github.com/input-output-hk/hydra/wiki/Logbook). It's usually a one-way type of communication (you cannot comment on a wiki, only read/receive information). The main advantage over a plain folder with files on the repository is that it makes edit a bit simpler as it can go through a different workflow.

• We could imagine moving the biweekly notes there, and also links to agenda of the various meetings.
• An F.A.Q. too, why not?

from cips.

thanks @michaelpj - I've added this to my TODO. Will find out in the meantime about the precedent for whether the relevant Wiki content should be duplicated or linked into CONTRIBUTING.md (please post if you have any suggestions).

According to open source standards it seems important that this document should stand alone in a cloned repo but I wouldn't want to duplicate too much content between CONTRIBUTING and the Wiki. 🤔

from cips.