As @moshwrote last month, Protocol Labs (who initially created and incubated IPFS) are working to help make IPFS fully independent and owned by the community.
One step we’re taking is to set up a provisional Steering Committee. That sounds fancy but really what it is is a small group of people dedicated to shepherding the non-technical mission and values of the IPFS Project as well as its overall strategy (you can read more about what that means in the charter).
A key goal that we have as part of that is to make the IPFS project democratic, and that’s why we’re calling this “provisional”: the current people on Steering have been appointed by fiat but our job is to set up everything that’s needed so that we can be kicked out gently replaced by people elected by and from the community.
We’ll be following up with details about how that will work — in the meantime, thoughts, issues, screams are welcome and you know where to find us!
Maybe instead of a Steering Committee there could be a “Documentation and Developer Experience” committee for the work already done.
I’m not sure how a Steering Committee focusing on “non-technical mission and values” helps.
There just doesn’t seem to be that much traffic here on the forums to need a steering committee.
I’ve noticed an “engagement cliff” as developers move from the fancy standards sites, videos, and training sites to actually using the software. I’ve seen that lurking in the forums. Maybe the focus should be more technical - you might get more engagement through technical leadership vs non-technical leadership.
From the outside looking in, a steering committee seems more academic than functional. There appears to be a technical debt that’s unaddressed in the project and a steering committee seems to be adding an organizational debt on top of that. From the outside looking in, it feels more like an impersonal control/permission structure.
Maybe organizing twice monthly code workshops would be more effective?
I disagree that there is no need for a non technical forum. Just because there is no activity from non technical individuals on a forum aimed at and only attended by technical individuals doesn’t mean there isnt a need for it – it just means you haven’t pulled them into a discussion. It seems a bit myopic to use as evidence such a non-inclusive source.
As someone who works with many people who could and would be open to use it if it were more intuitive and user friendly, and could demonstrate actual value and use cases to the average user, I think opening up a larger discussion could be useful, and I think developers might be able to learn about what is more useful to create for the community (and how to grow that community)
Let me offer two pieces of evidence from a more inclusive platform: YouTube.
This would seem to indicate there is 2x more interest from non-technical users then from technical users, as the simpler, non dev interface seems to have more interest.
Two points that I think are worth making: 1) it’s not an either-or choice and 2) it’s about governing the IPFS project, not just this forum.
There are multiple active technical groups, like the Implementers WG or the IPFS Dapps WG (and many more). In fact, there are enough groups that having a coordination function like Steering to help make sure that all those groups are supported, coordinated, etc. makes sense.
As @walkerlj0 notes, there are multiple venues of interest and engagement, and we need to make sure that they work. We also need a global approach to growing the community.
If you see technical debt, please point out where. There are multiple teams working on several implementations and they are reactive to bugs as well as adding new features and making specs for them.
True, and documentation and developer-experience are being worked on in parallel. One of the top priorities of a “non-technical”-scopes Steering Committee, traditionally, is working with the documentation folks and dev-ex folks closely, as they have the most and best input on who is out there falling off cliffs and how much money it would take to build them stairs.
If you have specific documentation and/or dev-rel ideas, feel free to open threads on the forum and tag me, i can tag in the appropriate people or just put things on my own to-do list as needed.
Thanks for the conversation @bumblefudge and everybody else. I’m very much for IPFS and think it’s solves a bunch of problems about to happen to the internet.
I’ve been working on an electron app, first attempting a custom Kubo plugin and now using Helia. Sparing the details, both clients have alot of repos/packages and it’s really hard to get something working. Some things are undocumented. Some appear buggy or unfinished. Some I’m using wrong, but it’s hard to tell which is which. I’m still trying to host a website through an IPFS gateway after a lot of fussing with it. I’m replacing an old cable modem to see if that helps.
I’d be interested in whether the meetings for this WG / committee will be recorded / have notes or other output like other working groups do.
Are filing issues in GitHub - ipfs/steering-wg: IPFS Steering WG the best way to provide inputs to this group, or are there other ways to provide community feedback to steering committee members?
Having a list of artifacts the steering committee is responsible for or intends to maintain might be useful in helping to be clear about the scope of responsibilities for the group.
We’re still setting up norms, but the idea is that yes. This isn’t a secret conspiracy.
For now, the issues tracker is the best way to reach the group but we’re open to other options. We’re also talking about broader things like Pol.is to garner input.
Agreed — we’re inventing things as we go along so we haven’t pre-emptively listed anything, but we’ll update our page as we incrementally define things better!