e2h —vs— other collaboration tools

< DRAFT++ >

vs Wiki, hedgedoc, markdown, google docs, ms word, etc.

    20210822 merged in 🔗ethering-why part → D+
    ### [!!*] rename page ... pads-are-better ? pad-vs-everything ? ###
    20210829 read → D++  almost rfc

Ties to:
    * 🔗E2H
    * 🔗e2h-todo
    * 🔗ethering-why — "why to ether" vs "easier tools"
    * 🔗workflow


* Use BOLD to indicate features that can/ought to be adopted by e2h.
This ties to 🔗e2h-todo.

* Use RATINGS (--/-/+/++):
    * written from the tools perspective
    * rated from E2H's perspective:
        (++) E2H is critically better here
        (-) E2H is worse here
        (!) means to pay attention / it's complicated

*** e2h vs ...

"ms word" or "google docs"

Ties to 🔗ethering-why !

(++) are bloated:
    Neither E2h's view or edit mode will not overload/overburden your computer with bullshit

(++) are capitalist, big brother, etc:
    If not yesterday or today, we will find out tomorrow that this is a good idea

(-) seems simpler:
    Certain E2h features are more cumbersome ... but, so what?:
        "We Shall Not Take Foreigner's, and Not Give Ours" (YU) (### contextualize better)
        With a little bit more discipline we will get to a better place.


In the end, their systems always turn out to be limited when you adopt actually serious workflows.

(!) example: commenting!
    At the beginning it seems nice, but then... :
        * people start "resolving" comments which had content conversations in them (and those are lost)
        * ... or were not actually "resolved" yet
        * you have no way to prioretize edits
        * ###
    ... So you again, start improvizing.
    Better to do it on your own terrain / stage, even if at beginning somewhat more precarious, will ultimately get you further.

(++) worse data portability

see https://github.com/ether/etherpad-lite/wiki/Understanding-Etherpad's-Full-Data-Export-capabilities


(--) search
(-) categories:
    (!) partial categories / pad marks
(-) headers/sidebars etc
(-) complex extensions
(-) opendata etc

(++) no real time collaboration
(+) spam prone
(++) order of magnitude slower editing
(++) less intuitive / ubiquitous than pads  (smaller participation barrier)
(++) more difficult to give (specific) pages a legibility towards different textual/content types
(++) ... especially TOCs
### SPECIFIC, move out [!]
(+) no simple & powerful graphs
(+) no graphs spidering

(++) no authorship colors
(+) clunky revisions system
(++) markdown will limit how expressive it can be
(-) tags on revisions
(-) has user model (but it is very loose by default!)
### see ethering:antlies about that [←!!]

(-) is FLOSS
(?) does not need a comrade license

evaluated via https://pad.hacc.space/features?both
[!] login with twitter / something that's not infra4future

(-) co-scrolling (though, 2-tab editing is faster)
(++) no authorship colors
(++) clumsy when multi-edited
(?) charts
(-) todo boxes
(-?) logins
(-) blockquotes
(~) externals
(-) nice graph support :
(-) horizontal rules
(-) tables
(--) footnotes
(-) Abbreviations (definition extras)

(++) uses the botched markdown syntax


botched syntax for dynamic, collaborative action:
(++) internal link system
(+) ordinal system of headers ("h1")
(+) overly strict, tells you what to do, rather than the other way around
(++) won't support to copy-paste in (with no clear tools available)
(+) markdown is for geeks 

use markdown?
well, it was just a suggestion...
i know, i got it 100x times
hackers like to talk about things that don't matter
i adopted and produced 10x more content in markdown on the [hacc] hedgedoc than all others combined
that's the important part
the fact we keep talking about "which syntax" and "which chat software" to use is a disease of the hacker kind
nobody is immune but we need to develop a culture which ridicules it rather than encouraging it. haa ha
### #nothacker #posthacker