What I've learned from working with ProleWiki

And what I can teach you when it comes to organizing people

If you like this article, please don’t hesitate to click like♡ and restack⟳ ! It’s a quick way to make sure more people will get to enjoy it too.
And don’t hesitate to subscribe to my newsletter for free to receive my new articles right in your inbox!

I’m a designer by trade, with more practical experience than theoretical.

In 2020, I joined the nascent ProleWiki two months after its founding when I read my (soon-to-be) co-admin’s essay On Drug Use. Prior to that, I thought of ProleWiki as an interesting project, but not one that I necessarily wanted to join. That all changed when I read that piece; that’s when I realized the potential behind that platform.

Back then, everything was still to be decided on ProleWiki. It started as a loosely-defined project of which only one thing was sure: making a wiki for Marxists. This is actually a great design choice, and we’ll get into that later.

I joined the administration in early 2021, along with several other editors, as a way to help develop a clearer line for ProleWiki and formalize what its role could be for people around the world.

Personally, I think that design overlaps a lot with marxism. If we hold that everything is dialectical (and it is), and if we hold that everything exists in the material world (it does), then we could refine the saying as: “Design is just a subset of Marxism”. From there, we realize we can apply design to our organizational work.

… and if I lost you by talking about dialectics, don’t worry: I’ll explain what that is soon in a way everyone can understand (and will put a link to the article here). It won’t prevent you from reading the rest of this article which, from this point on, will be entirely about design.

Since my early days on ProleWiki, I’ve stayed on the administration through the highs and lows, and have developed features, principles and ideas of my own on the website (such as our new Portals). Today, there’s only two admins coordinating everything: me and my co-admin Forte, the aforementioned author of the essay above.

The reason we have been able to grow so quickly — not just in term of what we offer but also in terms of how many people visit and talk about us — is because we follow a design approach to our work, which structures and focuses our problem-solving and solutions on what is actually impactful.

Here’s some of the things I learned from this work which I’ve been doing for 3 years now, and which I hope you can learn to apply in your own organizing or outside of it.

Everything is a problem with a solution

I actually find this very freeing. If there’s only two parameters, and you have to act within those two parameters, it also reduces the chances that you start going the wrong way. It keeps you focused on the only path that you have before you.

In design, everything can be boiled down to a problem. And every problem, by definition, has a solution. You just need to find both the actual problem (this is where design thinking can help) and then one solution. Not the solution — just the best one you think you can do under your circumstances.

There’s always limiting circumstances: time, skills, budget, etc. to give just a few examples. The point when designing a solution is to be realistic with what you have and apply those resources where they will be most impactful, to the best of your ability.

Learning to identify problems and then think of solutions is a process and is actually two different skills. Some people are great at figuring out the problem, and not so great at proposing solutions. These skills are honed with experience and reckoning with reality — you can’t fake your way to it, it has to come from actual situations you find yourself in. But, you shouldn’t think of solving problems as a professional skill only. It can help you in your daily life as well.

I myself have become solution-oriented in my daily life, and while I don’t want to claim this approach will work for everyone, it does help me stay focused and not start overthinking. When things get tough, I think to myself there has to be a solution, I just have to find it. It’s pulled me out of difficult situations more than once.

Let’s think of this simple situation: you’re thirsty. Problem: you don’t have anything to drink at home. Solution: run to the store and get something to drink.

That’s a simple problem with an understandably simple solution. But the problem-solution process can also help with much more complex problems, and we’ll see in the next sections how you can achieve that.

Once we know what a problem is and know when we’ve found it, we can start figuring out ways to get there.

Learn to think like a designer

Design thinking has been rationalized into a very structured process that goes through five steps. In simple (but seemingly abstract) terms, it goes like this:

1. Understand your audience. Put yourself in their shoes — it’s easier said than done! Ask yourself the questions they would ask themselves. Take the time you need (it can be hours or it can be days, there’s no prescribed time limit) to really understand their situation. It’s important to listen and ask questions. At this stage, you shouldn’t even be thinking of the problem yet. You’re making sure you understand everything that’s laid out before you.

2. Define the problem. Once you understand who you’re dealing with, isolate the problem they face — and the right one. Sometimes, people might think they have one problem but the real problem is actually something else entirely.

3. Ideate. Start thinking of solutions. Measure how realistic they are and how impactful they would be (we’ll get into that), and isolate one solution that you’ll implement and try out.

4. Prototype. Make your solution tangible, actually bring it into the world. It doesn’t have to be perfect, it just has to exist from the idea to the actual enacted thing.

5. Test it. Bring your solution out in public, let it play out, and then see what comes out of it. See if it succeeds, or fails.

It’s important to note that sometimes you might go back a step. These 5 steps are not rigid and don’t necessarily follow each other linearly; as you become more acquainted and comfortable with the process, you’ll know when to break the rules and when you’re going the wrong way. Sometimes, you might test your prototype and realize you got your audience all wrong. Then, use that feedback to refine what you thought of your audience and start over from step 2. It’s all part of the process.

Let’s illustrate all of this with an example. Workers at the Tricoins coffee shop are not happy with their conditions. Their manager is not allowing them to sit down even for a second, and wants them to always be doing something, preventing employees from taking breaks. Their common complaint is, “I wish I had another manager, a nicer one!” You take a good long look at the situation: how the store operates on a day-to-day-basis, what other things the workers have to say, what the manager has to say. Yes, even the manager needs to be interviewed to get a full picture of the problem! At this stage, you can’t judge the situation you’re facing as it might lead you to the wrong solution. You must take things as they are, without judgment, and get a full picture, as full as you can get it. You have understood your audience.

You quickly realize the problem is not the manager but the franchise itself. The franchise owner is putting a lot of pressure on the manager to meet unrealistic quotas. Replacing the manager will not change anything, a new one will still be pressured to keep to the expectations. You have identified the actual problem: the franchise owner needs to chill. Generally, the problem can be expressed as a question (and it’s good practice to start doing that). It can easily start with How most of the time. How do we get the franchise owner to lay off with the micromanagement?

Next, we have to ideate solutions to the question we raised. In this step, I like using brainstorming sessions, just collecting ideas and letting people in the group discuss them openly as they come up. Brainstorming is valuable because it helps get past the very first step, the blank page syndrome, which is often the most daunting one. What are some solutions we can think of for this problem? You could talk to the franchise owner and ask him to be nicer to his employees. Well, this seems like an easy enough solution that doesn’t require too much effort (in money, time, labor, etc.), so let’s try that. You talk to the owner and he doesn’t care about any of the employees’ problem, he just wants to see the profits rolling in. You’ve tested your solution and it was inconclusive at solving the problem, and so we go back to ideating.

What else can we do? Well, let’s look at the problem some more. We realize the employees don’t really need a manager, the manager is just here to meet the quotas set by the owner. So how about the manager becomes an employee like everyone else, and the store speaks as one against the franchise owner’s interests? We’ve ideated something else here.

You write down a unionization plan: you’ve prototyped a solution. Then, you present it to the employees and they all agree to unionize.

The boss has no choice but to accept this decision (in reality, he will try to fight it and this will likely have to be settled in court, but for the purposes of this example let’s say they were able to unionize while the boss was on his vacation in Mexico). He can’t fire the entire store for unionizing and if he did, he would have to re-hire an entirely new team from scratch. We’ve prototyped the solution and are now seeing it play out, testing it and waiting to gather feedback.

You come back a month later to see how the store is doing. Now that they have no manager, the employees are not being bossed around anymore and are much happier. They have very few complaints now. You’ve tested your solution after taking the appropriate amount of time for it to play out, and saw that it worked out great. Congratulations! And if the employees still have some complaints that need addressed, you can apply design thinking again and again to tackle all the new issues that have come up now. There is potentially no end to it.

The beauty of design thinking is it can apply universally; I’ve yet to find a situation where I couldn’t apply this process. It’s just a matter of finding the right problem, and everything follows.

Learning design thinking is not super easy. It’s not really something you can just read about and understand like you might math or physics; it takes practice to internalize it and become comfortable with the process. In other words, it’s a soft skill. But this also means that on the upside, anyone can learn it through experience. Before I started to really get into design, I wasn’t much of a designer.

Remember: the difficult parts are understanding your audience and bringing out the right problem. Finding the right solution is often much easier once you have a clear, coherent problem figured out. And the whole point of the method is to help you do exactly that.

Getting ready to sprint

Once you start to get design thinking and see results, you can try a design sprint. A design sprint is the 5 steps of the design thinking applied over 5 days, with one step being taken each day. This is a very efficient way of putting out a prototype (a first version that has the bare minimum viable features which you can improve on later), as you must publish something by the end of the 5 days.

On ProleWiki, we are starting to experiment with design sprints to focus our efforts and avoid people naturally losing interest. As our communication is entirely online, it’s very easy (I’m guilty of it too) to lose interest in a project you’re involved in. Then it gets revived two weeks later and everyone has forgotten what we were talking about or why we were even doing this project in the first place.

Being able to manage expectations, telling people clearly “if you join this sprint, we expect you to be active every day (but only for 5 days), so if you’re otherwise busy, please don’t feel forced to join” yields much better results. We will go into this in a later point, but I much prefer being in a small but active team of 3 than a big but inactive team of 8.

I’ve done design sprints in companies too, and there’s a whole methodology for each day (there’s an actual book on it, titled Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days). Personally, I think it’s fine to apply the methods the first times you try a sprint but as you become familiar and comfortable with the process, you will learn when to break the rules. And isn’t that what life is all about?

You can always go one step further

This is one of my own key principles. I call it the “Simpsons method”. Watch this 30 second clip real quick:

In this clip, there is not one joke, but five building on each other. First, Bart doesn’t see the street sweeper heading for him. His bike then gets caught in it, but it actually comes out looking pristine — these are the first and second jokes.

Instead of stopping there and moving on with the next scene however, the writers have Bart happily get on his bike, but then it breaks down — the third joke.

Then, Bart looks back at the driver who is laughing maniacally, indicating he actually ran over Bart’s bike on purpose; the fourth joke.

Finally, as the driver is laughing, he accidentally climbs on the sidewalk and falls down the subway station, and this is the final joke, and the payoff to the entire sequence.

This is the Simpsons method, which the writers used heavily in the earlier seasons of the show. They could have stopped at the first or second joke and moved on with the episode, but they applied the principle (back then at least) that there’s always an extra step we can take to make something even better. No matter if it’s a small or big step; it’s just a matter of finding it. 80-90% of a project is easily done, the hard part is getting the remaining 10% put into it when everything is getting close to perfect. To this, I am reminded of Saint-Exupéry’s words: “perfection is achieved not when there is nothing more to add, but when there is nothing else to remove”.

Bring everything to its logical conclusion would be another way of putting it. Carry your ideas to term when you actually practice them.

With that said, you shouldn’t fall into the trap of perfectionism.

You don’t have to be perfect, you just have to exist

This is something I often repeat to people. Nobody expects us to get it just right on the first try. We are often our own worst critic.

In design, we often talk about the MVP — not the most valuable player, but the Minimum Viable Product. As the name implies, the MVP is essentially the most basic thing that works; i.e., that allows you to test your solution.

Let’s say you’re setting up a party (the organization kind). You don’t need to think about your statutes just yet, your committee, or when you’ll hold the general assembly and where. You just need to start getting out there and do something valuable for the people. This is the MVP. Later, as your party evolves and grows, you can start slowly setting out to get what you need as it comes up.

The same principle was applied to ProleWiki. When we started out, we didn’t really know where the project was going to go or how it was going to evolve. We tried different things; for example, early on most editors were invited to become administrators to try and get them interested in the project again after initial hype had tapered over a few months. This worked out terribly, as we were simply not ready to accept so many admins: we didn’t have principles fleshed out yet, we didn’t really have a line we wanted to follow, and we didn’t even really know what our purpose was yet (today it’s become quite clear, and I’ll probably talk about it in another article).

But it’s okay. We didn’t have to be perfect from the start. What matters is we exist and, as time goes and we get feedback, it becomes clearer to us where we deliver value to people, why they visit ProleWiki and what they want to get out of it.

Our model is to cross the proverbial bridges when we get to them. For example, for a long time, the administrators approved or rejected account requests up to their best judgment. In late 2022, as we grew more active and cultivated an active base of editors, we started submitting account requests to the editors for a vote instead, and have been doing it ever since, thereby steadily improving democracy on ProleWiki. We recently voted to name a library and essays space maintainer, who are responsible for managing, maintaining and growing their assigned space, thereby allowing us to grow these two “parallel” projects within ProleWiki as spaces of their own. But a year or two ago, there would have been no point in having a library maintainer because it wasn’t yet a big or strong enough part of ProleWiki that it really needed someone to do this.

Our material conditions in the present moment dictate what we focus on.

Don’t hesitate to admit you’re wrong

This is difficult to learn, and sometimes we don’t even realize we are blocking a solution because of our own ego. I’m guilty of it too, I’m sure.

I would add a caveat though: you should also recognize where you were right in your assumptions (and we make a lot of assumptions in design, we just learn to make the mostly right ones). Because, being proven right means that you are obviously doing something correctly, and so it will confirm that your next uncertain decision is probably the correct one as well. Recognize when you’re right. You deserve it.

Likewise, understanding where you went wrong is extremely valuable. It allows you to learn and grow, not repeat the same mistake, and ultimately allows you to find the correct solution, which is what you want if you’re solution-oriented and doing design methodologies like the one in this essay.

For example, a problem we’ve seen on ProleWiki is that not many people are aware they can actually request an account and join the editorship. To help increase the amount of requests we get (increasing the conversion rate from visitor to editor, which is a division expressed as a percentage ratio), I designed a button that would appear on all pages for non-logged in users:

The forbidden button on ProleWiki

When clicking this button, which looks like our own “Edit” button, the user is taken to a page that explains one needs to request an account if they want to edit or correct a page, and a link is provided to the account request page.

---

Let’s quickly recap the design thinking process to this button though, just so you get a better grasp of how the process works.

Initial situation: we’ve noticed we don’t get a lot of new account requests, and we would like to make the editorial team bigger (this is one of our permanent goals.)

1. Understand why we don’t get many requests. From surveys, analytics and talking to our community, we realized a lot of people don’t even know they can request an account. Previously, we also thought our vetting process was too long. But looking at the data (how many visits we actually receive on the account request page), we saw what was actually the problem: the request account page is simply not clicked on a lot, which likely means people don’t know how to find it.

2. Decide on the actual problem we intend to solve: people don’t know they can request an account and join the editorship. How can we raise awareness of this functionality?

3. Ideate: what can we do on this front to improve the number of account requests? Place the account request functionality front and center was our chosen solution. A button is simple enough to add, and it will show on all pages. Let’s try that.

4. Prototype: create the button and deploy on the website. When clicking on the button, it will take you to the account request page. After testing, we also tried an in-between page that the button takes you to which explains why you should request an account.

5. Test: after a month, see if our numbers improve. If not, go back to previous steps as needed and start over from there.

---

I let this solution play out for a month to gather data before analyzing the impact it had, while sometimes making tiny changes (like the wording on the button) just to see if it made a difference with the numbers.

What I found was that people didn’t really care about the “Make a correction” button. My hypothesis was seemingly wrong; it didn’t increase conversion rates (i.e. receiving more account requests) and most people clicked back when they reached the in-between page that explains why one needs an account to edit.

But that’s okay. At least now we know what doesn’t work, and from there we can infer more data than is explicit to design a better solution.

Learning what didn’t work is part of the process

It’s important to know what didn’t work so that we can get the right conclusions. From the “fake” edit button, we learned that the in-between page was a barrier. We learned, when looking at our analytics, that most visitors to ProleWiki didn’t even click on it — meaning most people on the website want to consume content instead of creating it. To give you an idea, less than 1% of our visitors have clicked on this “fake” button despite it appearing front and center when you visit a page.

This is still valuable information though. It will allow us to craft a better solution down the line (to get more editors on the team). If we know that people from our website don’t really want to edit the wiki, then we know that we should look for editors somewhere else. We know that we should change our approach too, and maybe reach out individually to people we know and think would make good editors.

These are all possible solutions that, if we decide have potential, we’ll have to try out and analyze: we repeat a process of ideation → prototyping → analyzing; this is called lean thinking if you want to look it up.

Ultimately, we removed the button, and some time after that deployed a much better solution (but one that also took a lot more work): we enabled anonymous editing on our content pages. The button is pretty much the same, but now visitors to the website can directly edit a page anonymously. The edit then goes through a moderation queue where it is either approved or rejected by moderators. Compared to the previous “fake” button, friction has been lowered — it is much easier to edit without an account now — and we get valuable edits which help improve the wiki, so it’s win-win overall.

Rely on data

Data is important to do our work. In the age of big data, we tend to think of it as numbers, analytics, big brother spying on you, etc. It’s not wrong, but data is actually much more abstract. I would define it as:

Data is any quantitative (or, more rarely, qualitative) fact that can help us in designing a solution to a given problem.

Data doesn’t have to be numbers. It can be a book that you read, or a methodology that you learned. It can also be, as we just said, a failure that you’ve experienced.

Theory can be seen as data. When Lenin explains in State and Revolution why electoralism will bring us nowhere, he put it into practice and was vindicated by history. When we learn this for ourselves the first time, we have effectively gathered data passively.

But it can also be gathered actively. I’m a huge believer in surveys and getting feedback. Ask people for their opinion, and do it often. Ask party members what they think of the meetings. Ask what skills they have and where they would like to put them to work. Ask your friends what their biggest difficulties in society are right now. Ask, ask, ask. This is not only the first step of the design thinking methodology, it’s also how a party stays close to its base.

Data is different from information. Data, by itself, is just raw facts and numbers. If I say “we registered 5000 visits today”, what does that mean? Is it a lot? Is it lower than usual? Once we put data in relation to something else, we give it meaning and it becomes information that is actionable. If I add “well, we usually make 2000 visits a day” then we have information. 5000 is bigger than 2000; without any judgment, we can clearly see an objective relation between these two data points. So the question then might become, what happened to get these 5000 visitors, and what can we do to achieve these results again?

More broadly, we can simplify “accepting failure” into “learn what you can, take what is useful, and leave the rest out”.

Involve people that are interested, not those that are forced to be

I would rather work with 10 committed members than 1000 that barely give signs of life, and I think most of us would too. But let me ask you this question directly:

A socialist party is not looking to get big to show the conventional parties that they’re the biggest. We don’t recruit people for numbers, we recruit people who want to get involved in the struggle.

I actually see some parties making this mistake, trying to get as many members in so that they can appear to be “popular”. Then, two months later, all of their members stop replying to emails, stop showing up to events, and stop giving signs of life.

This, I believe, is a problem in onboarding. The party was unable to properly capture what interests their individual members and offer them what they need.

Certainly in organizational work we don’t always have the luxury of saying “I don’t want to”. But again, would you rather have someone who is dedicated in one task and does a great job at it, or someone who feels forced to participate in all sorts of tasks and half-asses all of them?

If you don’t like leaving your house but you’ll do overtime as long as you’re on the computer, then great. I won’t force you to come to meetups, and instead I’ll ask you to be on the social media team. If you don’t like social media, I’ll ask you: what do you like? Graphic design? Great, then we’ll ask you to do the posters and flyers.

If you like talking to people but you feel like you’re pestering strangers when you ask them to sign a petition, then I’ll suggest that instead of canvassing, we could use your sociable personality somewhere else.

It may seem simple, but this is something that I see parties and all sorts of organizations fail at all the time. They expect members to be experts in everything from the start and not say “no” to anything.

It’s a problem in business too. Our “soft skills”, which is our personality and other traits we learn through experience (e.g. design thinking), are becoming more and more interesting to employers. Nowadays, almost anyone can have a college degree and there’s thousands of people who have the necessary diploma for the job. But not all of them will get along with the rest of the team. Not all of them will stay in the industry. Not all of them will get the gist of the job and company in the first week.

In a non-profit setting like ProleWiki, we have the luxury of accepting whoever we want as we are all volunteers, and as such don’t have budget as a limiting factor. We started asking prospective editors what skills other than writing they have, so that we can start thinking about where they could help and eventually place them there.

If you like making videos, we can give you access to the Youtube channel. If you like teaching, we can have you patrol the edits new editors make so you can help them with the editor, sourcing, etc. If you’re an accountant, we can have you keep our financials table updated. There is essentially no limit to where we can place people and finding out the skills they have and putting them in the right spot is a skill in itself! But if you manage it, you will be able to give absolute trust in the people that do this not for you, but for the continuity of what you are collectively building.

Having ideas is great, being able to carry them out is better

I’m a fan of brainstorming. I see for myself every day how just talking to other people can help clarify both your own thoughts and theirs. How ideas you would have never had suddenly materialize in your brain simply by engaging in a discussion with someone.

I like brainstorming sessions for this purpose. In a brainstorming session, your team of designers talk about the problem you face for 15 minutes. Someone in the group writes down all ideas, regardless if they’re good or bad, and makes sure the session stays on track. However, I’ve found that letting people talk about other things (context for their idea, a relevant story that happened to them, etc.) during these 15 minutes also often yields even better ideas afterwards, so you probably shouldn’t understand “staying on track” to mean “being strict”. The time limit is important to make sure the session doesn’t drag on and people stay creative, but it shouldn’t be seen as a rigid session where one is only allowed to blurt out ideas in quick succession and anything else will get them a slap on the wrist.

Anyway.

Having ideas is just one part of the equation. Theory without practice is just words in thin air, and practice without theory is adventurism. We need both to exist side by side.

Realizing that you not only have the (brain) power to have ideas, but that you also have the power within yourself to try them out is important to form independent, creative users, which creates a strong organization.

On ProleWiki, we (well, it’s mostly me) always say that when someone has an idea they should not be lazy — jokingly — and carry out their idea themselves. Don’t wait for another editor to do what you see needs to be done, do it yourself right now. If you see a typo on a page, fix it. If you don’t like how an intro is structured, propose your own. If there’s a big article you want to start but don’t really know where to begin, form a group with 2 or 3 other editors and start writing this article with them.

This leads not only to self-responsibility, but it empowers people too. It makes them realize they have something to contribute and their presence is valued. It engages them in labor that pays off; they can very quickly see the actual impact they’ve had. For example, a member once made a meme about ProleWiki and we shared it on social media. It eventually made its way to Reddit and we almost set a new record of visits that day. I made sure to tell the comrade about this, not so much to praise them for their meme, but to let them know that their work had an impact, i.e. it led to a ton of visits, which were directly measurable.

I find it also prevents the curse of having too many ideas but too little time for each of them. People sometimes approach me with ideas that we could look at (like making an app, which we’d love to do but is a HUGE project). I always tell them the same thing: we have so many things that need to be done right now already, it would be better if they helped with those first. Then, once we’ve taken care of our backlog, we can look at new ideas.

This is a win-win situation: we get urgent things done, and people get involved with the project and realize that their involvement is needed and valued. And eventually, as we clear the backlog of everything we need done, we can look at adding new ideas in, including theirs.

A party works a bit differently. It needs a clear, unified line to avoid factionalism and disgruntled members working against the party. However, a party still has a strategic vision made by the central committee, and an operational side made by the members on the ground. It’s actually in this case especially that we can involve the “ground” members into strategic decisions, letting them propose their ideas for a vote. We already do this without giving it this name, and we call it democratic centralism.

How to prioritize your solutions

How do you find which ideas are worthwhile or urgent, and which ideas can be put down to take care of later? There’s a potentially useful tool called the ICE model (Impact, Confidence, Ease) but I personally don’t use it and I never recommend what I don’t use myself. What I do instead is prioritize based on the short-term, mid-term, long-term, and undefined-term.

I find that almost nothing is considered short-term (needing to be done urgently), and most things can be taken care of in the mid-term (3-9 months). Long-term would be 9-12+ months, and undefined-term would be something that would be nice to have but has 0 priority or takes too much effort for the return it would have.

The new Library page on ProleWiki for example was an idea I had for almost 6 months before setting out to actually make it. The impulsion behind it was simply “Our current library is kinda difficult to navigate, we can probably make it better”. That’s all I started with. Making it better.

During those 6 months, I was solely researching what exactly “making it better” meant, what I needed to take into account to make it (tech limitations set by MediaWiki mainly), how I wanted it to look, how it was going to be experienced by the editors and the readers (two very different audiences), etc.

Eventually, we ran a small survey in which I showed a mockup (a jpeg that shows what the library page will look like once it’s coded), which was received really well, but the project went dormant again for a few more months. After I’d finally figured out how I could implement the new library, it took me a weekend at most to get the MVP out (Minimum Viable Product) and then a few more days to iron out the fine details. A month after the new library was out, we brought some additions to save up on vertical space, which is at a premium on mobile, showing continuous prototyping and improvement. You never truly finish iterating.

The new library was a mid- to long-term project. The reason it wasn’t a short-term project wasn’t necessarily because of the difficulty of making a new library (as I wrote above, it took me a weekend to make it once I learned how I could code it on MediaWiki). It was long-term because we already had a working library page, even if it was a bit unwieldy — it was just a long page of text — and so we had all the time in the world to make a new library. It was not an “undefined-term” project because I knew I wanted to get it done some time in 2023 and not leave it hanging for too long, and that as soon as I got more familiar with MediaWiki and how to code in it, I could get it out ASAP.

Establishing a culture of constant improvement

All we’ve seen ultimately leads to a philosophy of constant improvement: the belief that there is always something to improve, no matter how big or small. It can be fixing a typo on your website, or it can be organizing an entire protest (getting the permits, etc). There is always something that can be done when you look for it, and all of it will have an impact. And constant improvement is recursive: you can organize your first legal protest. Then you can organize it better next time, getting the permits faster, or getting more people to show up. You can improve on what you improved.

Constant improvement is, incidentally, how China (which is the fastest-growing and biggest economy in the world) works, though I’m not sure if they have an official term for it.

Culture (in an organization or anywhere else) is eventually self-reproducing. We reproduce cultural traits we inherit from our surroundings (such as family, friends, or even architecture, art, the music we consume, etc.) and we pass them on to others as well. It works the same in an organization. If you are able to promote a certain culture, people will eventually carry it and pass it on to the new members. While it can take some time to get started (we still haven’t fully developed a culture on ProleWiki), culture can be very powerful: don’t underestimate it. But culture is created actively. If you told punks you’re one of them at a Dead Kennedys concert where you showed up in a suit and tie, they would laugh at you. That would negatively reinforce your identity, and the next time you would get some more fitting clothes. You can’t call yourself punk if your casual attire starts at a suit and tie, it’s just not part of the culture.

Likewise, we actively remind our team (and ourselves) to constantly improve. When they notice a glitch or typo and raise it up on the channels, I’m usually the first to ask them to fix it since they noticed it.

It takes time, but establishing the right culture in your organization or projects eventually leads to more and better involvement, fewer headaches, and generally just more value delivered. And it answers the question: what happens if the current administrators retire? Who will take up the reigns? What will happen to the project? In a collective project like this, we have a responsibility not only to ourselves, but to our fellow members as well. If we administrators did not sufficiently build our foundational strength, to the point that if we left, the project would fizzle out, then we have failed our members. This is not about ego, by which I mean the ego of seeing something outlive you. It’s about not letting other people down, depriving them of this place they’ve come to use daily, and each of them also not wanting to let others down.

All of my writing is freely accessible and made possible by the generosity of readers like you. If you enjoyed this essay, please consider supporting me. I’m on Ko-fi, Patreon, Liberapay.

Bitcoin (BTC SegWit network) - bc1qcdla40c3ptyrejvx0lvrenszy3kqsvq9e2yryh

Ethereum (Ethereum network) - 0xd982B96B4Ff31917d72E399460904e6F8a42f812

Litecoin (Litecoin network) - LPvx9z9JEcDvu5XLHnWreYp1En6ueuWxca

Upgrade your Substack subscription for $5/month or $50/year:

Share this essay: