Hey, this page is loooooooooooong, if you're in ?orchard and you wanna just write something and get feedback, then just do it! The following guidelines should not be discouraging or paralysing, but exist to help improve your contributions and give some direction to the wiki overall. It's version controlled and editable, so go and have fun :)
Intention
Permacomputing wiki is not Wikipedia, so being neutral or encyclopedic is not among our goals, and original research is encouraged. However, it is a collaborative project, so if you want to express an opinion the other editors may not agree with, please discuss it in the orchad circle, or the bbs forum. It can be possible that a page or entry needs to be written to take into acount multiple perspectives. Keep in mind however that we aim at hosting material that can help us move the discourse and practice forward, so pharmakonesque deadlocks should be avoided.
Wiki areas
We do not have fine grained permissions and would like to implement as little bureauracy as needed for wiki editing, so please be mindful of the following house rules:
home page: avoid editing. Its content is the result of a few years of trying things out, and it's good enough. If something needs to be changed there beside grammar/spelling. Discuss it in orchard
permacomputing design principles: do not edit. This section is updated through collective wiki edit-a-thons organised by ?bitrot. It needs to remain as stable as possible to be useful for everyone. Feel free to fix grammar/spelling though :)
the longer permacomputing introduction: avoid editing, same remarks as the Home page
characteristics: this page is an ideal starting point to add new and improve existing entries that can help better understand limits of computational systems and highlight better approaches
Getting Started: in dire need of cleanup, rethinking, and simplifications. Should probably be either merged or decoupled from topics overlapping with the principles or onboarding
Community: to update when info about new/existing groups needs to be revised. It should also be a place where we find info about the existing circles
Library: in dire need of cleanup, rethinking, and simplifications. Quite a few random things there that should be removed to focus only on key pmc texts/materials
Projects: needs some cleanup, but workflow is stable. Basically each project should have a oneliner and an internal dedicated page. A project page needs to follow a simple template with three sections: 1. a descriptive introduction, 2. a sections explaining the relevance to permacomputing ideas and principles, 3. a section about the limits of the projects, 4. a section with relevant links. Keep it short and to the point See cerca for a good example. Only add projects that are really relevant to permacomputing, not the first thing you find that you might find remotely interesting. The project entries can be written by anyone, and it's also an option to do that with the assistance of a project's creator(s), assuming they are willing to engage with the critical part about the projects own limits and challenges
Assessments: in dire need of cleanup, rethinking, etc
workshop: this page is an index for existing and new practical technical documentation, HOWTOs, IRL workshop scripts and material, project blueprints that could be reused by other groups, etc. The workflow is simple. For new projects 1. add/create your page in the "Work in Progress" section, 2. when finalised move it to the "Released" section. For existing released projects, feel free to update/fix/correct the material, however if you want to depart from it too much, just fork it and follow the workflow of new projects and indicate/links that this is based on previously released existing entry xyz, because it's nice.
(Copy)editing style
permacomputing, not Permacomputing
new pages are not capitalised
British English spelling for English content
do not line break within a paragraph
do not link to the main index. ever. this wiki uses an automatic backlinking systems and it's great, but we want to keep the main landing page free of backlinks
to keep the source text readable directly as plaintext markdown, only use two heading levels,
h1and h2, using the===and---syntax. If you need to go down toh3, consider using bold headers instead, worst case, use a###titleexplain the abbreviations before using it (ex. Operations Systems (OS) are amazing. The OS are actually shit)
make sure the references are explained before using them. (ex. "Unix is a multi-user operating system whose development was started in 1969 by Ken Thompson and Dennis Ritchie, as well as an entire family of operating system derived from the original Unix." First, explain the original Unix, or rearrange the sentences where you explain what unix is, then explain that there are multiple versions, an original and others). Same for people mentioned, quotes, etc.
explain the relevance of a quote
transition between paragraphs, quotes etc. is key. similar to the rule above, make sure the paragraphs are transitioning from one point to another
careful with jargon. if a technical/academic/etc term needs to be used, maybe it needs its own page as well. (i.e. "it refers to a very specific kind of 'digital', a highly technoprogressivist and industry-defined kind that became prominent in the 'digital revolution' hype of the 1990s." technoprogressivist is not a common word that could be understood easily, either provide a short explanation or make a page for it)
check if there are other pages you can crosslink in your text (i.e. you mention hardware, link the hardware page there)
avoid using brackets (as much as possible), it breaks the reading (and comprehending) flow (quite a bit) (right?)
avoid passive-aggresive language. rather, explain why some concepts are wrong/didn't work/are bad. (i.e. "digital revolution" hype of the 1990s. why was it a hype?; so-called "alternatives", why so-called? why air-qyotes?)
make sure all formatting choices are unified in your text. (i.e. https://permacomputing.net/Principles/ here, the sub-principles are written as a paragraph first, and then as list. should be the same style)
use formatting sparingly and with purpose
avoid repetation and redundant words, be concise, simple, clear.
if you see something, edit something :) really if you see a page could need some help with copyediting (specially those written in the early years of the wiki), just do it.
Images
No idea how to best deal with this... Anyone wants to volunteer? :)
Saving/Submitting
EDITING ON THE WEB FOR LONG SESSIONS WITHOUT SAVING INCREASES THE CHANCE OF LOOSING YOUR EDITS RIGHT WHEN YOUR SESSION/AUTH HAS EXPIRED AND YOUR BROWSER MAY NOT HAVE CACHED THE FORM CONTENT BEFORE SUBMITTING IT. In doubt for long edits, just quickly copy the form contentto avoid bad surprises.
editing via git is possible, but requires access to eik. WIP :)
On attribution, quotes and footnotes
At the current stage of maturity of this wiki, it is often not advisable to write a comprehensive articles about a topic if someone else has already done it elsewhere. Put in a link to that external resource instead. (In the future, we will perhaps want to host copies of all these "dependencies" in the local repository as well, but not yet.)
When introducing a new term, please try to include a proper and non-biased definition of the topic before proceeding to the permacomputing-specific points of view. You can use ?Wikipedia or other sources for this, just make sure you properly attribute and quote (we are CC0, Wikipedia is CC-BY-SA, so you can't just copy-and-paste even from there).
If you rely on other sources for the writing of a section, do not be lazy or mindlessly copypaste from other sources. In general, do not invisibilize people from which you took inspiration and/or learned something from. Take the opportunity of contributing to this wiki to also point to their work and research. You must properly attribute your source. You have 4 options:
Hyperlinks: Sometimes it's enough to point to external reference as an hyperlink if there is not much to discuss. For instance Ursula K. Le Guin has an interesting take on technology.
Footnotes: Can be handy to drift a bit1 but also to give a proper footnote reference when paraphrasing and referencing the thoughts of someone else. For instance Ursula K. Le Guin has been critical of a specific usage of the work technology when misused to only refer to the most recent developments, which also happen to be the most problematic2.
Inline quotes: Use this with footnotes when you want to quote something short inline. For instance Ursula K. Le Guin offers to understand technology more broadly as "the active human interface with the material world"3.
Block quotes: Finally, you may want to quote entirely a part of someone else's writing, in which case, use the block quote formatting, with a footnote for the reference. For instance here is how Ursula K. Le Guin suggests to reconsider how we use the word technology:
Technology is the active human interface with the material world. But the word is consistently misused to mean only the enormously complex and specialised technologies of the past few decades, supported by massive exploitation both of natural and human resources. This is not an acceptable use of the word. 4
Limitations of the footnotes
This it not biblatex/biber. So as you can see in the examples above, you cannot reuse an existing footnote, and there is not elegant handling of repetition (no Ibid.).
Reference style
When referencing, please use the Notes and Bibliography version of The Chicago Manual of Style. However, this is not an academic paper, don't overthink it or spend ages on it, try to make it work as best as you can, it's just to have some overall consistency. No sweat :)
Licensing
While editing the Permacomputing wiki, you agree that your contribution will be published and made available under the CC0 Waiver. If you use images, photos, from other sources, please make sure to give full credit and if available the license/tersm under which the image is made available.
- parenthesis could be used as well, sure, or long — em dashes, but if you're going to fork the discussion to something that's too long to fit in the flow of the main text, and that does not need its own page, then a footnote can be quite handy.↩
- See Ursula K. Le Guin, "A Rant About 'Technology'," 2004, http://www.ursulakleguinarchive.com/Note-Technology.html.↩
- Ursula K. Le Guin, "A Rant About 'Technology'," 2004, http://www.ursulakleguinarchive.com/Note-Technology.html.↩
- Ursula K. Le Guin, "A Rant About 'Technology'," 2004, http://www.ursulakleguinarchive.com/Note-Technology.html.↩