Codimd: What will become the future roadmap?(Or: Is CodiMD a wiki? )

[SISheogorath]

I think we should solve the question: Is CodiMD a wiki?

It sometimes really bothers me when people refer to it as a wiki, because I don't think CodiMD was ever created/developed with that directive in mind.

And according to Wikipedia's definition of the word "Wiki" we really don't fit into that category:

A wiki engine is a type of content management system, but it differs from most other such systems, including blog software, in that the content is created without any defined owner or leader, and wikis have little inherent structure, allowing structure to emerge according to the needs of the users.
-- Wikipedia

And also when I read their definition of the Characteristics I'm pretty sure they don't match on CodiMD.

---

However, I know various people use it as a knowledge base and in a "wiki-like" style.

So the implicit question following to this one is: What should be out future focus?

For a Wiki it seems more needed to have features like the link exploder, the ability to (cross) link sources and maybe even including things like BibTex for quotes and sources.

While, and this is mainly the way I use CodiMD, note taking and live collaboration during talks, meetings, as well as some personal note taking and quick docs have other requirements like annotations or a chat integration.

These are really important questions and may also lead to decisions about what kind of changes we want to allow and how invasive they should be. Every feature we add needs to be maintained and that means work. So we shouldn't grow into all directions. CodiMD is already very complicated to maintain and we have so many dependencies that I currently try to reduce them a bit in order to stay usable and secure in future.

---

This discussion started in the Matrix channel and was moved here to allow everyone to sort and add their thoughts: https://matrix.to/#/!ybaSlrrMNLeuoQuUuR:matrix.org/$1538037988269807tMJfx:matrix.org

[ccoenen]

It should be the greatest CodiMD ever.

More seriously: There are good wikis out there. CodiMD is not one of them. CodiMD is about realtime collaboration. Wikis (usually) are not. While I wouldn't discourage people calling this a wiki, I personally don't call it wiki. I don't think this needs to fit any pre-made shape.

[unteem]

Interesting. Something I have been thinking about a lot too :)

I like to refer to codimd as a "pad".

I don't think that codimd is a wiki, it is just something else. Something new that comes with a new workflow. It can cover what a wiki does but not entirely and has others interesting features that wikis do not provide. So we can try to make it a wiki, that would be just reducing Codimd to what it is not though. Still it does not mean that in the end you cannot use it as a wiki.

I would say though that features such as link exploder and BibTex for quotes and sources are a really cool features that wikis provide and that could make a lot of sense for codimd. But does that make codimd a wiki? I don't think so.

Can codimd play a part in your wiki or knowledge base system? Yes it should.

With IndieHost, we host 5 different instances of codimd. And codimd is just awesome for live and collaborative note taking and documentation. Having a quick layout with markdown makes my notes pretty standard so I can do whatever I want with it afterwards.

Actually, I miss this part at the moment. What happens next when I'm done writing my note/pad? Main limitation I find with codimd is that it does not have an api. So I can't do much with those notes afterwards.

So what I miss and I think that would answer your question, is an api. Then I can do whatever I want for my specific use case. I use Codimd to collaboratively edit my content in markdown, then I just need to talk to the api, get the notes I want and do something with it and be happy :)

I like to have a modular approach and I think Codimd, like all open source softwares, should be part of an ecosystem of tools. So to conclude, in my opinion codimd should focus on what it does well (collaborative editing in markdown) but have an open api to allow other tools to plug to it.
For instance if:

• I need to have a space to manage and share my notes, lets make a nextcloud app.
• I need to chat, lets integrate rocket.chat to codimd.
• I need a wiki, lets make a static site that looks like a wiki with those markdown files

We can go on like this. With this approach (in an ideal world?) you would not necessarily need to maintain yourself all those integrations/features.

I hope that makes sense. And I'll be curious to get @pierreozoux @almereyda @Rieul @nicolasloubet opinion on this matter.

[almereyda]

Great to see these initiatives flowing, esp. #911

The following legacy (meaning pre-Codi-rename) issues also come to my mind, and are also already on the way:

• #952 (#314 (#166) #653)
• https://github.com/hackmdio/codimd/issues/975#issuecomment-425734046

Asking for a roadmap in the same time asks for user needs for me, which is currently documented in the issues tracked here. Here we could fulfil an almost ancient request:

• #12

I agree a machine way to access notes independently of the frontend will be of use for further integrations. And for me as a user writing a hypertext with it, it is only most helpful if creating links between different pads is as simple and straightforward as possible. This can be achieved through various means of notation and UI feedback.

Grouping pads to public/(semi-)private collections, either through tags, category hierarchies or group spaces, is only helping to request content from an ever growing knowledge base. Given a content API, a more heavyweight integration with lunr.js, making its rounds in static site land, comes to mind, too. Or Discourse-style oneboxing, etc.

Is there a structured process emerging from #911 that would go through the backlog of issues and outline priorities and possible phases of implementation?

[SISheogorath]

Is there a structured process emerging from #911 that would go through the backlog of issues and outline priorities and possible phases of implementation?

@almereyda No, there is currently no structured process during community calls.

We also try to not make any final decisions there, since we want to have the whole community to be able to decide things, which requires some asynchronism. Decisions are made by:

1. People who implement something
2. Discussions on here GitHub
3. (indirectly) the community chat
4. Me and @ccoenen as maintainers (Don't expect too much, we basically work on the points 1 & 2)

The reason why we don't really priorize issues, is that I don't expect that to work. We are all working on CodiMD in our free time and this way we spend the time on what we think is fun to implement or we need ourselves. My previous trials to get my own development process structured, turned out to be quite bad and not working very well. That's why I think we should talk about the direction, not about which issue we want to fix first/next :)

[almereyda]

À propos CodiMD + wiki : https://github.com/weseek/growi :eyes: ...

• https://github.com/weseek/growi-docker-compose/tree/master/examples/integrate-with-hackmd
• https://github.com/weseek/growi-docker-compose/tree/master/hackmd

[SISheogorath]

Yes, I saw this a few weeks ago and was nosy, but never checked out in detail (like setting it up myself).

But it shows how CodiMD can integrate with things even without being a wiki itself.

Sadly I have no idea how interested the maintainers of their project are in working on us. But let's get back on topic :)

[smugderby]

One of the things I think of CodiMD is a collaborative interface to content. Which means that you can use it collaboratively for content in a pipeline of publishing that content in various other formats. So in the end it can be a publishing platform but also enable publishing platforms that use git repositories to generate customized static sites. For it to be that in the future would require more integration with git repositories, in that the final individual files can be pushed to git after online collaboration is done.

[almereyda]

Now that @CodiMD exists as a separate organisational entity after #1170 on with its codebase being maintained in https://github.com/codimd/server, it appears useful to move the open issues over there.

From there we could continue to triage malfunctions, feature requests and organisational communication specifics like #1145

Also codimd.org should primarily direct to the new project, instead. In the following, a separate landing page could appear feasible.