1,496
edits
User:Martind: Difference between revisions
From London Hackspace Wiki
no edit summary
No edit summary |
|||
| Line 34: | Line 34: | ||
* You will likely be more successful by handing the problem over to a group of people who get along well and then letting them take charge. Accept that if you don't show up and contribute then it'll be hard for you to influence the outcome. | * You will likely be more successful by handing the problem over to a group of people who get along well and then letting them take charge. Accept that if you don't show up and contribute then it'll be hard for you to influence the outcome. | ||
* Making change is hard: it involves lots of initiative, and the patience to try again until you find the right way to make it work. It may entail having to change the habits of many people who have no reason to listen to you. This is by design. (And yes, it's not always good.) | * Making change is hard: it involves lots of initiative, and the patience to try again until you find the right way to make it work. It may entail having to change the habits of many people who have no reason to listen to you. This is by design. (And yes, it's not always good.) | ||
=== Infrastructure Projects === | |||
You can assume that most work at the Hackspace is purely self-motivated, and this generally works well. However in the context of infrastructure projects for the Hackspace as a whole (tool maintenance, access control, renovations, ...) this approach can become problematic. A great way to stop *any* progress is to announce a fancy project that addresses key shared concerns, and then stop working on it without telling anyone. This happens surprisingly often. | |||
Experience shows that some adjustments can prevent problems later on: | |||
* Make sure to tell people about your plans. Otherwise there's a good chance you'll get distracted by silly misunderstandings and oversights, and lots of redundant labour. Strictly speaking you should probably also inform yourself about what other initiatives came before yours, and build on them. | |||
* Don't be too protective of your work and turn yourself into a bottleneck; instead allow others to help you whenever you are stuck. Find the local specialists. When coordinating group work: [http://wiki-archive.emfcamp.org/2012/articles/m/a/r/User:Martind/Induction.html#Making_Important_Decisions Involve your community in larger decisions]. | |||
* And most importantly: make a habit of handing over your work to others once you realise you don't have the time/patience/resources any more to support it. Don't just drop it and run away. | |||
These suggestions reflect the nature of infrastructure work: others may be relying on you to actually finish. However taken together these suggestions may make your spare-time experiment feel like tedious "work": depending on your personality type and mood you may feel like the overhead is tar-sanding your project, and it becomes hard to stay motivated. So in the interest of progress it is sometimes best to keep quiet; apply your best judgment whether this applies to you, and avoid creating needless bottlenecks for others while you play. | |||
=== Informal Authorities === | === Informal Authorities === | ||
| Line 51: | Line 61: | ||
** Is there a least-effort equivalent to a guided induction? E.g. safe zones where people can be active participants in our culture without having to feel tested? | ** Is there a least-effort equivalent to a guided induction? E.g. safe zones where people can be active participants in our culture without having to feel tested? | ||
** How can we reveal existing intangible bias in our decision-making, make it tangible without being confrontational about it? | ** How can we reveal existing intangible bias in our decision-making, make it tangible without being confrontational about it? | ||
=== Recommended Reading === | === Recommended Reading === | ||
