3 ms·

The foremost use of a technically oriented public communication space is 1) Access to experienced persons with a depth of knowledge that exceeds your own 2) W

The foremost use of a technically oriented public communication space is 1) Access to experienced persons with a depth of knowledge that exceeds your own 2) Whatever good feelings one gets from staying informed about technology and helping others with issues 3. Archiving the knowledge and the solutions contained within the space In #3 mailing lists fail splendidly. * I have never been able to easily follow a archived mailing list thread (why do the reply links bounce around and never are in chronological order?). * they tend to be rarely searchable from the web. * If one does not know the people on the list and their reputations and bona fides, evaluating the accuracy of information is difficult * They are scattered all over the place and are un-findable unless you know exactly where to look For the reasons above any sort of web forum or reddit-like platform is preferable for posterity as long as the information remains accessible on that platform.

mjevans 3y ago
#3 Ideally the 'archive' is that stuff which is unclear or poorly documented gets updated in the documentation, so it doesn't come up again.
9dev 3y ago
I’ve been involved with technical documentation a lot by now, and think the only actually working solution for archiving and passing on knowledge is something like a Wiki, combined with something like GitHub discussions, where individual discussions can lead to change requests or new articles. That way, discussions of the topic could lead to changes on the canon.
- csydas 3y ago
  I do agree with the idea of wiki is the right way, but I think most orgs overestimate to an extreme degree how much work a "simple wiki" (my words) really takes to be useful. One of the disadvantages of a mailing list that is actually a surprise feature is the lack of content curation; as pedantic as the wikipedia edit wars might be, having tried to maintain a wiki for one of my work places, I understand why they happen, even when you have a well documented and followed structure and content guideline that everyone is aware of. Generating consistent and accurate content, and curating said content, is really a full time job, and for technical content neither item is something I'm comfortable sourcing to a group that isn't also able to contribute to content on their own in a meaningful way, as this can really harm the value of such a wiki. I think the tooling is less important than the dedication to developing a structure, enforcing the structure, and curating what gets into the documentation very hard. Mailing lists kind of avoid this because they neither propose to be curated no require someone to decide "today I will write X and Y articles", the interest and the discussions define the direction of the content creation. Great for getting data out there, but not great at being searchable or meeting user needs for relevance.
  - hutzlibu 3y ago
    The main work with wikis, is keeping them up to date. Worse than no documentation is wrong documentation in my experience. So if there is a vibrant community, than solid ressources like the Arch Wiki can get created and maintained ( but even there I encountered out dated, or wrong information).
    - 6510 3y ago
      I've pondered how one could set up conditions in documentation. For example display [collapsed] code in the document that implements the functionality there described. If the exact code is no longer found in the source the article or section gets a warning banner, a [collapsed] div view and the wiki bug tracker displaying the issue. Perhaps one could also programmatically generate a list of missing articles by looking at code and implementations.
    - midasuni 3y ago
      I Try very hard to explain why we don’t document facts on our wiki, but concepts, with links to facts. We aim to maintain a single source of truth of what should be, and have automated systems to tell us what is. Want to know what ip server “lon-rds14” should be? Ping it. DNS is driven from the ip mgmt tool, job done. Check the auto populated cmdb which will tell you the current interfaces on a given host to tell you what ip it really is. Want to know where on the network it is? Search the portmapper, which tells you (through switch labels) where the host should be, and through mac/ip/dns where is actually is (cmdb also has the lldp entry - duplicating data that automatically updated is fine) On our work wiki (20k users), different departments copy and paste information from one page to another so it’s in “their” area. Even worse one department locks down its area so it’s hidden to those outside the department!
  - 9dev 3y ago
    To be clear, a Wiki as it is isn’t the best possible tool to gather knowledge about a specific topic in general, even if it works for the Wikipedia. Kind of like how git isn’t perfect for projects other than the Linux kernel. I agree that dedication is vastly more important than tooling, but simultaneously you need a medium that is both simple to use and suited to preserve and accumulate knowledge; somewhat of a middleground between a long PDF document and a Slack channel with 10k messages. At this point, I’m pretty sure it must be easy to get new topics out there, then hone them step by step into something useful for the future.
u801e 3y ago
> I have never been able to easily follow a archived mailing list thread (why do the reply links bounce around and never are in chronological order?). The ease or difficulty really comes down to the client you use. If you use a email client that can import an archive file of the list and display messages in proper threaded order. The other option is to use a NNTP gateway service and read the threaded discussion. Gmane used to provide it. public inbox[1] is another service that may work. [1] https://public-inbox.org/README.html https://public-inbox.org/README.html
andrepd 3y ago
Mailing lists don't have to suck or be unsearchable. See sourcehut: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/<000001d97d57$caca69b0$605f3d10$%40niktivan.org> https://lists.sr.ht/~sircmpwn/sr.ht-discuss/<000001d97d57$ca...
zajio1am 3y ago
> For the reasons above any sort of web forum or reddit-like platform is preferable for posterity as long as the information remains accessible on that platform. Web forums force everyone to use one UI provided by forum operator, while technologies designed around conversations (mail, netnews (RIP), IRC, Matrix and others ...) allow everyone to choose their preferred clients/UI. That itself is (for me) web forum disadvantage outweighing most other aspects.
zelphirkalt 3y ago
I am not sure all GNU mailing lists are archived, but the ones I read are very well searchable and threads well explorable in the browser. I follow along daily digests and Thunderbird displays threads nicely. I tag some or move them to my archives in Thunderbird. If I cannot find something, I check in the browser.

mjevans 3y ago

#3 Ideally the 'archive' is that stuff which is unclear or poorly documented gets updated in the documentation, so it doesn't come up again.

9dev 3y ago

I’ve been involved with technical documentation a lot by now, and think the only actually working solution for archiving and passing on knowledge is something like a Wiki, combined with something like GitHub discussions, where individual discussions can lead to change requests or new articles. That way, discussions of the topic could lead to changes on the canon.

csydas 3y ago
I do agree with the idea of wiki is the right way, but I think most orgs overestimate to an extreme degree how much work a "simple wiki" (my words) really takes to be useful. One of the disadvantages of a mailing list that is actually a surprise feature is the lack of content curation; as pedantic as the wikipedia edit wars might be, having tried to maintain a wiki for one of my work places, I understand why they happen, even when you have a well documented and followed structure and content guideline that everyone is aware of. Generating consistent and accurate content, and curating said content, is really a full time job, and for technical content neither item is something I'm comfortable sourcing to a group that isn't also able to contribute to content on their own in a meaningful way, as this can really harm the value of such a wiki. I think the tooling is less important than the dedication to developing a structure, enforcing the structure, and curating what gets into the documentation very hard. Mailing lists kind of avoid this because they neither propose to be curated no require someone to decide "today I will write X and Y articles", the interest and the discussions define the direction of the content creation. Great for getting data out there, but not great at being searchable or meeting user needs for relevance.
- hutzlibu 3y ago
  The main work with wikis, is keeping them up to date. Worse than no documentation is wrong documentation in my experience. So if there is a vibrant community, than solid ressources like the Arch Wiki can get created and maintained ( but even there I encountered out dated, or wrong information).
  - 6510 3y ago
    I've pondered how one could set up conditions in documentation. For example display [collapsed] code in the document that implements the functionality there described. If the exact code is no longer found in the source the article or section gets a warning banner, a [collapsed] div view and the wiki bug tracker displaying the issue. Perhaps one could also programmatically generate a list of missing articles by looking at code and implementations.
  - midasuni 3y ago
    I Try very hard to explain why we don’t document facts on our wiki, but concepts, with links to facts. We aim to maintain a single source of truth of what should be, and have automated systems to tell us what is. Want to know what ip server “lon-rds14” should be? Ping it. DNS is driven from the ip mgmt tool, job done. Check the auto populated cmdb which will tell you the current interfaces on a given host to tell you what ip it really is. Want to know where on the network it is? Search the portmapper, which tells you (through switch labels) where the host should be, and through mac/ip/dns where is actually is (cmdb also has the lldp entry - duplicating data that automatically updated is fine) On our work wiki (20k users), different departments copy and paste information from one page to another so it’s in “their” area. Even worse one department locks down its area so it’s hidden to those outside the department!
- 9dev 3y ago
  To be clear, a Wiki as it is isn’t the best possible tool to gather knowledge about a specific topic in general, even if it works for the Wikipedia. Kind of like how git isn’t perfect for projects other than the Linux kernel. I agree that dedication is vastly more important than tooling, but simultaneously you need a medium that is both simple to use and suited to preserve and accumulate knowledge; somewhat of a middleground between a long PDF document and a Slack channel with 10k messages. At this point, I’m pretty sure it must be easy to get new topics out there, then hone them step by step into something useful for the future.

u801e 3y ago

> I have never been able to easily follow a archived mailing list thread (why do the reply links bounce around and never are in chronological order?). The ease or difficulty really comes down to the client you use. If you use a email client that can import an archive file of the list and display messages in proper threaded order. The other option is to use a NNTP gateway service and read the threaded discussion. Gmane used to provide it. public inbox[1] is another service that may work. [1] https://public-inbox.org/README.html https://public-inbox.org/README.html

andrepd 3y ago

Mailing lists don't have to suck or be unsearchable. See sourcehut: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/<000001d97d57$caca69b0$605f3d10$%40niktivan.org> https://lists.sr.ht/~sircmpwn/sr.ht-discuss/<000001d97d57$ca...

zajio1am 3y ago

> For the reasons above any sort of web forum or reddit-like platform is preferable for posterity as long as the information remains accessible on that platform. Web forums force everyone to use one UI provided by forum operator, while technologies designed around conversations (mail, netnews (RIP), IRC, Matrix and others ...) allow everyone to choose their preferred clients/UI. That itself is (for me) web forum disadvantage outweighing most other aspects.

zelphirkalt 3y ago

I am not sure all GNU mailing lists are archived, but the ones I read are very well searchable and threads well explorable in the browser. I follow along daily digests and Thunderbird displays threads nicely. I tag some or move them to my archives in Thunderbird. If I cannot find something, I check in the browser.