Most of the documentation still needs quite a lot of work, we do not have yet a strategy and a clear flow about how to deal with contributors (such as a list of good first issues, or a solid list of common experienced/solved issues), and most of the developers who try to setup a bonfire instance ends up not having a pleasant experience.
Just a summary from our Matrix chat today, with some additional remarks…
Ease contributions and dev onboarding by relating open issues to PR’s and/or commits.
Might be better if stand-alone modules have their own issue tracker.
Decision to stay on Github (benefit from network effects) or move elsewhere should be made soon, imho.
You have extensive plans for Bonfire developer experience. Might publish them for public ideation/feedback.
Consider publishing the BON-** issues related to EU funding and people assignments.
You prefer ‘Dogfooding’ (e.g. Kanban tool) your own dev process. May make that a very explicit plan.
Entire build harness is going to be rewritten. It is good to know plans beforehand.
There may be plans to move to Rust, eventually to WASM. Essential to know at least something about this.
The website offers a very high-level ‘end-fedizen’ roadmap (okay, end-user oriented ). May create a much more detailed developer-oriented roadmap, that includes the focus on elaborating software development process and community governance.
It seemed that you want to move to dogfooding certain aspects asap. Then it is good to know where/when this will happen, as all organization structure that is migrated is effectively temporary. Plus the dogfooding will lead to requirements for the codebase/product. It may be an idea to manage it as a small separate project, or maybe just a separate board. Maybe everything related to community, governance, dev processes etc. can be grouped in a separate repo for tracking, idk.
You can consider C4 = Collective Code Construction Contract as a dev process.
We are trying it with OHN, and although we are not very successful so far, I still believe it’s very good process. I’ve done something similar in other, proprietary, project, and had very good experience with it. It’s highly scalable (in ZMQ there are ~500 devs) and inclusive, if you plan to build big community of contributors on Bonfire. In OHN I’d “blame” luck of project management and organization skills of a person who happens to run the project (me!) then the process itself.
Some links you can find below, @weex can probably say much more.
If you’re open to learn more about Collective Code Construction Contract, I’m happy to answer any questions. Still proving it out with Ecko (Magic Stone’s Masto fork) and Acropolis (diaspora*) so it’s substantially theoretical but we’re having a good time and consistently making progress on problems that the community finds valuable.
I really like the chats on matrix, and a ton of useful info is mentioned. But the amount of it will become unmanageable and TL;DR real quick. As soon as something actionable is mentioned it should be spun off to be tracked elsewhere and preferably delegated to someone that wants to address it or monitor it.
The long tests in the chatroom are full of these missed points. If they are not followed up with an issue creation or a forum topic creation then in 2 months time they will be forgotten, and you have to have the discussion and explanation anew.
@bhaugen in Matrix from here mentioned the UX design for thread hierarchies, and interesting discussion ensued. Great back and forth of ideas. Some also mentioned in the toot that triggered the chat.
Now, I think none of us are UX designers. We must bind more than just devs to the community, obviously, and having a separate UX track be part of project organization is one of the things that can be very beneficial. How that can look like?
Plenty of ways. First of all maybe planning the project/community organization can have its own repo. Then a whole host of stuff can be considered for a UX track from low-hanging fruit to more elaborate plans, eg:
I was not aware of penpot, and great to finally see an open source alternative that seems valid! Will give it a try, but imo before spending times re-creating the whole bonfire design system there I’d like to create some engagement here on the forum or on our matrix channel
Given we use surface to develop bonfire clients, the only alternative i’m aware of to build a component library is GitHub - surface-ui/surface_catalogue - but it’s still in the early days and the experience is not really smooth at present.
FYI in our last meeting we decided to stick with a single issue tracker for the next period, as we do not want to bind us too much on github. We’re in the process of splitting todo list in atomic issues, so that they can be tracked with PR and commits.
As since the launch of our new website we got some interests from different lovely humans that wanted to hack on bonfire, I was thinking to start a new thread to gather feedbacks and suggestions to help us writing the bonfire documentation.
I’d be happy to hear stories from you and @mariha about how’s challenging you and your orgs the C4 adoption!
After a first - rapid read, my main concern about adopting / pushing C4 for bonfire is that it seems to me C4 works pretty well when you have one or two repositories to maintain, but what happen when you have contributors and maintainers that work with dozens of different repos at the same time as in bonfire?
IMO the whole workflow could be quite painful and time consuming , am I wrong?
Also, the C4 methodology seems to work well in a ecosystem mostly built by developers for developers, one of my interest is to decentralize the power and include into the development , decision making, duties also several other figures - which it seems they do not have really a space in the C4 flow.
Am I missing something? (i’ll bet I do)
Multiple repos can be a challenge for any community to track but what C4 does in the end is to make the job of a maintainer very simple. Instead of organizing code reviews and making judgements about what gets merged, the maintainer simply looks at the issue a given PR addresses and tries to determine whether it’s the right problem to be working on.
The quote from the protocol is “accurate and valuable” so most of the work is actually for the community to discuss which problems are accurate, the right problem, not a symptom of something deeper, and valuable as in worth the community’s time to be addressing.
Before C4, I’d always thought maintainers were responsible for whipping code and devs into shape before merging, so it made sense when they asked for changes but then it’s something else when code sits, approved even, and still isn’t merged. If you look, you’ll see this all the time. With C4, we merge… realizing that the software is only going to work if we care enough to curate around the various PRs that come in.
Having been maintaining Ecko and Acropolis and a couple others for a few months now, nobody’s expressed pain. We merge code, sometimes ask folks for fixes to pass CI, and spend most of our non-dev time talking with folks and looking for those accurate valuable problems to solve.
The history of how C4 has been used was in ZeroMQ and yes that’s a very developer-centric community but that’s why we’re excited to be proving it out. If you’re into decentralization, you must appreciate the power of protocols for giving everyone clear contracts by which to operate. C4 makes a contract out of project maintenance while decision making is boiled down to judging the validity of problems. In all we find it very freeing. No roadmap, no grand designs, just problems that can come from anywhere, just like solutions.
It’s still a tough sell to switch to C4 which is why we decided to fork these projects and operate independently to see what happens. If you want to try it, I’d recommend forking one of the bonfire repos or create a new project, that way if after a few months it seems not to be working you can drop it, no harm no foul. If it works though, it’s very easy to adopt elsewhere.
tl;dr C4’s efficiency is needed even more when you have more repos. You can’t do better to decentralize something than to define a protocol for everyone to operate by.