Post History

I'm going to categorize "improvements" into two main categories: "Social" and "Technical".

## On Social changes

I'm categorizing Social changes as what you've termed "Site Concept" in the question. I don't think they quite require changes to the entire concept of the site, but cover social norms and etiquette and policies/culture on the various communities in the Codidact Network.

### Social norms and etiquette

To be blunt, social norms are very difficult to change. People are set in their ways and it's not easy to get individuals or communities to change that. However, the best way to even start that process is to **set the right example**.  
It's a bit cliché, but they do say "be the change you want to see" because it's true - if you want a change to happen, your best bet is often doing it yourself.

This applies to anything such as communication style, politeness, voting culture - anything that is down to individual choice and doesn't need community consensus to change. Unlike...

### Policy changes

Some of the social norms come down to various policies. For instance, a policy of editing out salutations and other noise in posts can lead to a culture where people are reticent to leave comments because they don't want to be "noisy". Changing policies is easier than social norms, but there is a process.

Most policies are set on a per-community basis. That means to change those policies, you have to get that community to agree to that change. The best way to do that is usually to start a separate Meta discussion within that community for the policy you'd like to discuss. Before doing so, I'd strongly recommend looking into the history of the policy and the arguments made in favor and against at the time that it was implemented; be prepared to either answer why it was the wrong decision at the time or explain how circumstances have changed enough to justify changing it.

For those rare network-wide policies, the same advice applies, but those discussions would happen here on Codidact Meta instead.

## On Technical changes

### The nitty-gritty on actually making changes

There's a bit of a backlog for technical changes at the moment, I'm afraid. Many of the core developers behind the project have gotten busier and less available over the past year or two. This is a volunteer-run project, and real life always comes first. However, it does mean that changes have been a little slow in being made.

What can you do about it? Well, if you're a developer, you can dive right in and start working on it yourself; all the code is [open-source](https://github.com/codidact/qpixel) and we do have several people who keep an eye on Pull Requests to test and deploy changes. (Technically, I have deploy access, although it's rare that I use it.)  
If you're not a dev, you're welcome to invite friends who are, or try to dive in anyway - people in our Discord server are friendly and usually willing to help new people learn the ropes and get them oriented. Some of the issues on GitHub are labeled "easy" or "good first project" (I don't remember the exact language offhand), which new coders or contributors are encouraged to tackle.

### A step back: Deciding on changes

Although before a Pull Request or code change is made, most changes to the platform undergo some sort of discussion and approval. People report bugs and request feature changes here on Meta, and then, depending on community reception, those are then moved to GitHub issues with a linked Meta report. Directly submitting a pull request or code change to modify the platform without prior discussion is usually discouraged, outside of very small changes or obvious mistakes being fixed. (It'd be silly to require prior Meta posts before making a PR to fix typos, for instance.)  
If you're unsure if the change you're considering making qualifies as "very small", you're usually best off just posting to Meta or asking on Discord - we're a community of pedants who love to discuss fine details, so don't worry about posting about minor issues.

## The Plans

We don't really have "high-level executives". We have seven Board members - of which I am one - but we all operate pretty much at ground level, just with extra paperwork once or twice a year. With that said, there is the [Codidact Technical Roadmap](https://meta.codidact.com/posts/285470). It's a little out-of-date, but should still provide some insight into where our priorities lie as a team.

As for how to get your hands dirty, you're encouraged to dive into the code, as I mentioned, or hop into the development Discord server to keep an eye on changes as they happen and get a glimpse "behind the scenes" at how the platform is maintained. We look forward to more people getting involved :)