workshop

This is a space for drafting and workshopping bits of software-related writing.

Currently, the ideas here center around a pattern language for making humanizing computer systems. See the patterns directory.

Here, "humanizing" refers to the effect that computers should ideally have on people and their relationships with each other. It does not imply "making computers more human-like".

Why

See why.md.

What

This repository:

• is public.

• will never be "finished" or publishable; rather, it is a community resource from which the raw materials of publishable works can be mined.

• is a space where we can let our weirdest and wildest ideas run loose.

  • but please illustrate your weird ideas with lots of examples; it's hard to talk about ideas without something concrete to point to. —benchristel

• Our scope includes code, software architecture, user interfaces, team dynamics, and open-source communities.

• Our quest is to seek the quality without a name.

Who

I'd like to consider the needs of various groups impacted by computer systems. Users, nonusers, product owners, programmers, designers, sysadmins. Whatever we end up writing, we have to make sure programmers are on board with it, because they ultimately determine what gets built (and they'll likely be a large part of our audience). But having multiple viewpoints is vital. One possible goal of this work is to convince programmers that they can live harmoniously in the world; that holding themselves to high ethical standards is not stupid. —benchristel

Collaborating

This repository is structured in a way that I hope will encourage collaborative, piecemeal growth.

• You can add a pattern to the patterns directory by following these instructions.
• You can add links to the References file.
• If you have feedback on a specific pattern, you can start a discussion, wiki-style, in an italicized block or quote block within the pattern text itself. Below is an example of this.

[benchristel] I prefer patterns to be concrete, specific, and grounded in our experiences. Any positive experience you've had creating or using software is a potential seed for a pattern. If you've also experienced the pain of not having the pattern in your environment, so much the better—that's evidence that the pattern actually does something. But you don't need a lot of evidence to write the pattern. Patterns can (should?) start out as just hypotheses; over time I'd like to test each pattern more rigorously and see if it really holds up.

Further Reading

The following resources help explain what patterns are all about.

• The metapattern.
• Martin Fowler's "Writing Software Patterns"
• A Pattern Language, by Christopher Alexander et al.. The original pattern language; this one is about physical architecture, not software. The book is also available as a PDF.