This Wiki was supposed to be migrated and moved, but due to a lack of effort (for various reasons), I, Peter did not make this happen. Because of this, the Wiki was down for a while earlier this year and has been and can be regarded as deprecated.
So what to with this?
New solutions and old solutions for the problem this Wiki aimed to solve are both "pad" (web-based collaborative real-time editor) based, see
I commit to keeping this site runnning until at least three months after the next in-person CCC Congress or Camp best I can, which in all likelihood would be March 2023.
To ensure this, even if the PHP daemon dies again (which it well might), I am considering offering a static, read only version of this site.
Alternatives to make sure that no content get's lost would be to convert the contents of the Wiki (as is) to ZIM, as decribed here
How can you help?
Please offer ideas, chime in, tell me what would work for you. The best way to do so is on this page. Thank you!
- Hello, Peter. What do you mean by "the PHP daemon died"? Is this wiki is running on a Debian-based or Arch-based Linux OS? Those make it easier for servers running open-source software to stay running and up-to-date. If a service goes down, the admin could write a bash script that automatically restarts it. I'm guessing you know that already. Most wiki software including DokuWiki require PHP too.
- Three other bugs:
- Etherpad, HedgeDoc, etc. are fine for temporary and personal markdown or text files, but they have much less control than wikis do against spam. While they do have a learning curve that stumps most bots, they have very limited or no support for access control, user authentication, content moderation, etc. Many wiki software do, including MediaWiki and DokuWiki via extensions. I can suggest some extensions later.
- Markdown is convenient for simple, temporary text files, but it's cumbersome to read around inline formatting and links and scroll for footnotes. Tables in markdown are ugly and can't be sorted easily by column. Many different markdown standards exist that a given text file could use that editors would have to learn, and even people just reading are likely to have to learn what the formatting codes mean and would probably be frustrated reading all the codes sprinkled throughout the text. Etherpads make linking between pages a mess and searching a group of pages impossible.
- Wikis are the best tool for writing and archiving documentation, tutorials, or journals. Their best features are not just collaborative editing and revision control but linking documents, searching, managing them, and offering most of their tools through a very easy interface for new users. Links between pages are crucial for discovering and organizing information and building a web of knowledge. Consider your audience most of all.
- I have several years of experience editing different MediaWikis, DokuWikis, Trac wikis, and use Zim offline. I have a little bit of experience using git, and I strongly oppose requiring git if you want your readers to become editors. Its learning curve is extremely steep, and it and its tools are not designed for being used as a wiki.
- On Mastodon, you asked people to get in touch with you if they "know some wiki platform that... has tools to pull mediawiki content over". The keywords you want to search for are "import" or "export". But if you compare wiki software (), you'll find that MediaWiki itself has the most tools for importing and exporting various formats, the most help documentation and tutorials, and has extensions that are more refined and actively developed than those of other wiki software.
- This wiki is self-hosted, but if admins would rather a third party hosts their wiki, here is a comparison of wiki hosting services. Miraheze looks like it would be the best of those for climate activists, but it blocks Tor.
- I hope this message reaches you because I decline to give my e-mail address to Matrix before it will allow me to connect to the channel, and I don't want a Mastodon account associated with my activity on this wiki. I use Tor Browser. That also gives me an unusual perspective about the design of access controls. Thank you for allowing me, a Tor user, to register here.
- Spam management and content moderation
- Delegate roles. Give Bureaucrat and Administrator rights () (permission roles) to people you trust to review page revisions. Copy-paste or import or link to as many features, templates, guideline documents, or organizational policies as you want from Wikipedia and its trove of help pages () or from other wikis that use open licenses. If you need reliable helpers, advertise this wiki! Send direct toots to high-profile users of Mastodon instances for the climate justice movement. Here are a few instances for climate activism:
- Block anonymous edits. (This wiki does.) Require a username to edit pages (this wiki does) unless your wiki has a large population of trusted, reliable, active editors who review revisions. On the registration page, make it optional to supply an e-mail address or social network account (this wiki does), but require completion of a non-Google (non-tracking) Captcha or TextCha and/or a hold of 12 to 48 hours denying permission of the new account to edit pages of the main namespace (as opposed to Talk pages or User pages). This is so that editing is allowed without an e-mail or social network account and that those wiki accounts will accumulate reputation so abusive accounts can be dealt with more effectively than if they were IP addresses, even by contributors who register through Tor. (This wiki uses a TextCha, but it asked me the same question twice.) Wikipedia implements similar restrictions on newly registered users until they are autoconfirmed. New accounts that remain inactive for, let's say, a week or two possibly could be automatically deleted or blocked.
- mediawikiwiki:Manual:Combating spam
- mediawikiwiki:Manual:Autoconfirmed users
- mediawikiwiki:Help:User rights and groups#User_group_expiry
- Securimage captcha
- Captcha chosen by Tor Project's BridgeDB,
- wikipedia:Wikipedia:Recent changes patrol
- mediawikiwiki:Manual:Preventing access
- Disallow (not block) the basic editor account group that has only basic permissions from committing extensive changes to a page all at once in one revision. This is so people who review other people's edits will not face being flooded by combined changes lacking context for the smaller changes. In the world of git and databases, these concerns led software project managers and reference guides to recommend "atomic commits" although it may not have to be so extreme on a wiki. In Trac, a bug tracker and wiki system, the threshold to disallow a commit is rolled into a "karma" calculation for each commit to the wiki (called a "submission" in Trac's documentation). Also related is the derogatory usage of the term, "cowboy coding".
- There are other MediaWiki tools for editors that make it easier to review and revert page edits, but they don't appear to be as urgently needed for this wiki as spam management tools are.
- By the way, remember to indent replies by prepending colons (:) to every line of text like I did in the wikitext markup of this comment. Multiple colons indents multiple tab-distances (:::::).
The focus of this wiki
Since anyone can register, what is the focus of this wiki? What topics are allowed? If people with the For Future Alliance, Extinction Rebellion, or Sunrise Movement came to this wiki, would you allow them to create pages for their needs too? I think they would gain a great amount of cooperative mutual aid from something more archival and concentrated than scattered pads, e-mail threads, chatrooms, and video meetings that are ephemeral and hard or impossible to search. --Cefra (talk) 20:16, 28 October 2021 (CEST)