As we know some of our more active community members do write forum articles on various topics as community knowledge base. A while back we had option to do such thing in old wiki site. But that has been cut of for ages now. So we plan to add one more major category in forum Knowledge Base with two sub-categories MikroTik and Community. In there for Community sub category I plan to add group based RW access for wiki-only article creation. For access to this group Technical writers users will be able to request access. After access is granted users will be able to post wikis in that sub category.
Ideally, I see that users that do create these technical articles would create post there and keep updating those articles instead of letting those articles get lost in-between standard category posts. And just like these knowledge base wiki’s in normal posts are reference.
Anyway, I’ve been attracted to the idea behind graphviz… in practice, I’ve never found it “easy” to do a simple diagram.
Now, perhaps, if RouterOS could “export” the firewall or queue as a Graphviz (e.g.export /ip/firewall/connections format=dot)… I might feel different, but that’s not the case – even than SVG still be better for a “visual export” of config.
I mention this since if one could start with a diagram of something that be lab’ed, then “just” have to explain it. That likely encourage more topological examples. And it that category of user-contributes we miss. So anything that can be done to “streamline publishing” of some working test setups be useful.
A separate forum section for Wiki is a great idea. There are a number of good articles already on the forum that should be moved there. I agree, some of them are somewhat lost unless one knows what to search for.
Is it possible to have a subsection there for user scripts? Those are not really knowledge articles but provide ready solutions for specific needs.
Great idea! I would suggest adding all of the certified trainers to the technical writers group since most of us tend to publish MikroTik related content.
Not suggesting it’s limited to trainers, just to add trainers to that group automatically.
Personally, I think y’all should do more thinking on this “Category” before using it. I’m sure not alone trying to get used to the new software… so exactly how a “contributor” manage an owned topic is hard to envision right now.
Instead, I’d focus on “tagging” and “views” to use the tags, and some “shared bookmarks”. In lieu of “migrating” a post to the Knowledge Base, at least for a bit.
Tag Ideas…
Here I have less ideas, than process around them… But a few are:
container-setup - describing how to setup a specific “docker image”
recommendations - “best” practices that are not specific to feature or protocol (like to avoid term in tag, since “best” is relative)
topology-examples - a lot of the “old wiki” would fall into this category (and been few in “old forum”) basically example using multiple routers or enterprise/carrier/DC.
script-snippet - actual script example, typically /system/script things
config-walkthrough - how to configure some feature or protocol using RouterOS syntax
multivendor-interop - not a lot today, but these kinda stuff of how RouterOS work with class of cisco/juniper/etc. is exactly stuff that be in a traditional KB (since other vendors change things, which make it hard to be in “real” docs)
Perhaps like /system/logging=topics, there could be another set with protocols or features, that could be combined with one of the “tag types” above to narrow down searching.
feature-request and help wanted and others should perhaps be tagged, but that doesn’t have to make it but focus on paths to KB ones.
Phase One — #Tag First
Views of Tags
Whatever “tags” exists, they should be views (i.e. shown in left navigation). For example with a container-setup tag, a corresponding view for “Container Setups” - this avoid trolling the Containers category. No new writing needed, and a list “community-test containers” be easily findable.
“Shared” Bookmarks
Like I know there are “bookmarks” here, and already started to use that “mark” posts I wrote that were more exemplary (or potentially useful pontifications). But bookmarks are “private” today.
In my case, I’d just to make bookmark public… I have 4K+ posts. I’d guess 1-2% of my posts have some durability and more broadly potentially useful that post at hand.
Basically, I’d like to “hijack” the existing Bookmarks feature, to create an _Ammø’s Favorites
More “Reactions” to indicate
Emojis just examples! The point is to use the existing “love”, “thumbs up” mechanism to find things that should be promoted/expanded/taged – or may belong in formal docs. For example, people may “Love” a witty or sardonic post — that isn’t same as “Love” on a cleaver solution.
- “This should be documented”
Which could be MikroTik or users, but there is some list of these be nice.
- “Needs Tag”
I do not all users should be able to tag, as that defeat it as “filter” for views.
- _“Should be Promoted to KB”
One way something make it’s way to the new “Knowledge Base”.
- “Potential Bug”
Similar to docs, while a lot of “potential” bug are config error or “misunderstanding”. But with a bunch of “reactions”, what was WAD may be appear as a *) feature - stability improvements. But this perhaps “flag” the need for a KB with workaround or “how your wrong on how this works”.
Phase Two - Use “subcategory” for Proposed KB
While verdict is out if Discourse can be made into a document management platform… The approach I’d take be more is “lightweight IETF” is their should be three subcategories:
published - only author can edit/comment, perhaps outside some group MikroTik/moderators who decided to “facilitate” moving some final output from the “purposed” thread into a top post in “published”
discussion - since a bunch of comments will clutter a “published” post IMO, for each published post, a corresponding thread in this subcategory be created on a one-by-one basis to “published”.
purposed - while above be "restricted’, any user should be able to post here, like IETF’s independent contributors.
Why published is “author only” replies?. IDK but I’m thinking of @rextended’s snippets as straw man here. If he had one “published” post, then each snippet being a reply. That allow Discourse “Quote” button to pull one particular snippet with a button. Which get harder if there were a dozen post from random users “this script didn’t work” – since it’s possible, the “discussion” be the place to tell @rextended he has bug.
This community KB side would function better if articles have maintainer. Which is why I prefer that members them selves sign up as contributors here, instead of us creating wiki articles in place of original poster or maybe new maintainer of article. Then they can create ports their ports to wiki articles them selves. And leave original posts just as discussion topics only for those wikis.
Tried mermaid-graphs out in test env. Seems ok. Might replace Graphviz with it. As Mermaid component is maintained by discourse devs, instead of Graphviz plugin which is 3rd party.
to indicate
- “This should be documented”
- “Needs Tag”
- _“Should be Promoted to KB”
- “Potential Bug”