Questions

• BSD License (3 Clause)

• Four main points:
  1. Availability
  2. Collaborative development
  3. Transparency
  4. Education

• A successful community recognizes problems and organizes itself to solve them.

Different developers have poured their heart into their projects, dedicating large amounts of time and effort into making solutions, and sharing them with the world. While the code may live online somewhere forever, an open source project only truly survives if someone maintains it.

• 6.0 (main release, annual)
  • 6.0.27 (bug fixes)
• 6.1
• 7.0

• Web accessibility matters.
• Standards Compliance
  • W3C's Web Content Accessibility Guidelines^[link9]
  • Web Content Accessibility Guidelines (WCAG) 2.0^[link10]
  • WAVE – Online accessibility validator^[link11]
• Markup and Stylesheets
  • HTML5^[link12]
  • CSS3^[link13]

• together we have much more power to encourage other people to get involved and reduce fragmentation
• we really have to pool our limited resources in an effective way
• breaking down the language barriers
• building a good shared infrastructure
• community before code

• The community of WackoWiki users should be respectful and cordial to encourage problem-solving and idea exchange, not ego-boosting, point-scoring, or one-upmanship.

• Open, Transparent Planning and Execution
  • Discussions over the forum^[link14] and the newsgroup
  • Contribution of source code submitted to Bug Tracker
• Infrastructure: repository changelog, issue tracker, ...

• Politeness lets us learn from those we disagree with.
• The more you know, the less you see.

1. we excel at doing stuff, and are lousy about talking about it

1. If something is not being done, it’s because no one has decided to do it.
2. Development culture means that people work on what they’re interested in.
3. He who does the code gets to decide.

• Principle - The LessIsMoreFeature to help against creeping featurism.
• uses a minimalistic approach
• JavaScript should not be required for basic usage (No reliance on JavaScript)

• Design by removing problems, not adding features
• Simplicity beats functionality
• Discover the core problems
• Solve them minimally
• Use that to discover next set of problems

• Verschlimmbesserung
• Komplexitätsverstärker

1. https://github.com/unprotocols[...]b/master/2/README.md^[link17]

• When your team starts routing around the tools you've offered them, pay attention: it may be a sign that you're offering the wrong tools.
• The more we invest in structure and organization, the stupider we become.

• Small units of code are good. The smaller it is, the easier it is to understand.
• Create and use simple, readable code

• One way to undermine social media monopolies is to refuse to contribute to the communicational economy they are based upon: don’t generate exploitable signals, stay quiet — and ask how this might be developed as a common response. Given the naturalized assumption that ‘more communication’ will automatically produce ‘more freedom’, suggestions, like this one, that are based on doing less of it might provoke hostility. However, in the case of the social media industries, communication is cultivated not in the interests of freedom, but in the interests of growth; social media wants to capture more of you through your transactions. Moreover, through this process communications are not made ‘more free’ but tend rather to become less open — certainly in the sense that they are commoditized. With this in mind, this paper asks if a media politics might be generated based on the potentials of silence, on speaking in tongues — and on relying on the resources of metaphorical language rather than on learning to speak or write in ways more amenable to code.