Not liking other alternatives, such as "Icecreaming" (too vague), "Drink your own champaign" (too posh), and "Eat the food you cook" (too long).
A definition may be:
> Self Delivery is a continual improvement method whereby the creator of a solution is also a client that uses it, gaining insight in how the solution conforms to stated needs, that are fed back into the design proces.
I've noticed some people refer to me as a dev, although I never claimed to be one. One person even accused me of not having recent commits in Firefish. So... I have to confess I am not a dev.
My role in Firefish was community manager/project coordinator. But isn't it interesting that people assume I'm a dev because I was in the core team? It's so often that community-driven open source projects are run only by devs, that people just assumed I am a dev too. And, with all the respect to the wonderful dev community, I think that's kind of a problem.
You see, an open-source project needs much more than coding. My role in #Catodon will include coordinating development, designing features, testing, communication and feedback from the community, managing issues on the repo, decision making, moderating catodon.social, participating and moderating the matrix channels and I'm sure more will be added to that list. Devs may or may not be good at these things - and this clearly affect some projects. Being a good dev doesn't necessarily mean being good at everything around running an open source project, and that's ok. There's a reason companies hire project managers when developing software. You can add every community request out there - if you don't keep UX on your mind and don't have a consistent vision for your software, it will end up poorly designed and bloated.
So, I have to warn you - I may not be suitable to answer your more technical questions! We have a support channel for that, and our lead dev Namekuji is more knowledgeable about the coding aspect - while other devs, who are interested in our direction, have already reached out and are starting to work with us. So hopefully we will soon have a lively dev and admin community where we can support each other.
I'd say that one of my main goals in Catodon is to offer a safe, inclusive and laid back environment where open source devs will be able to cooperate and contribute in a productive way. Making open source code is a wonderful gesture, you are sharing your work for everyone to freely use. And it deserves to be done in a well organized and self-fulfilling way! Good communication is not always easy, but it's definitely worth trying. We have incredibly talented coders here that can do wonders when working smoothly together. That's the mindset with which we'll be trying to make Catodon a community-driven project.
There's ultra-tech focus. Many projects start as hobbyism by a dev, then they grow and many different aspects come into play.
At (informal) #SocialCoding movement we defined the term #FSDL: Free Software Development Lifecycle, to include all good practices from inception to end-of-life of a project within its broader surroundings (community, ecosystem) to get to more inclusive processes.
Very interesting long read on “value capture” — when measurements like grades, citation counts, or step counts take over the true values (learning, writing, health) you actually care about. Also related to “stop the numbers game” by David Parnas (“Counting papers slows the rate of scientific progress”).
I'm fascinated by this. I began #SocialCoding movement ("Coding is Social") from observations on social dynamics in grassroots movements, particularly #FOSS and #Fediverse, where the former is inherently unsustainable (for participants) and the latter needs "substrate formation" (people + processes to evolve ecosystem/standards), which is ultra hard. We defined the #FSDL, a holistic Free Software Development Lifecycle. Research-to-practice is also part of it.
Remind me: have we talked much, here, about my notion of the “convivial stack”? This is the idea that, to the greatest extent possible, community governance, the built environment and the technological surround should all, simultaneously be designed so that they are open, participatory and actively invitational; modular, user-modifiable and extensible; and reward experimentation?
Though topic isn't elaborated much, #SocialCoding adopts a holistic view on the entire Free Software Development Lifecycle, the #FSDL. Which then includes the question "How can fragmented small initiatives find cohesion and thrive in a sustainable ecosystem?"
Observation is that the ecosystem must be healthy, so it can evolve. And 'Ecosystem focus' is often absent.