hi all! first post here, but you might have seen some of my comments and PRs so far
i’m really interested in a lot of the ideas here. the adoption of a proper CoC, clearly stated values, and focus on a proper community governance is really appealing considering recent events. and technically speaking, the separation of languages into multiple repos to form a top-level is a really great alternative take to handling a large nix repo that i would love to explore more
now originally i was going to continue this post with some suggestions on what else we might want to do in stage 1, along with some things we might not want to do. it’s still early after all, and it seems things are pretty rapidly changing (at least on github. i haven’t read much here just yet). i figured it would be a good time to maybe start discussion on some things
so reading this was pretty disheartening.
i had some initial reservations on how a roadmap was posted along with the announcement of the project, as something meant to be governed by the community should usually have the community decide on that - not just a founder. i assumed this would change though, given the stated values of representation and collaboration…but this leads me to believe otherwise
i would highly encourage modifications of the current roadmap, as this is quite literally the future of the project
i would also say this is a misstep. after forming our values (done), governance and means for the community to be heard should be the priority; otherwise, our stated values don’t really mean much or even have a way to be enforced properly. compare this to the current roadmap, where massive technical and organizational decisions are being made with 0 input. for example, in phase 3:
Flakes will be standardized with its current implementation as a v0. While not ideal, the feature is used far too widely to be changed or removed without breaking the ecosystem. Instead, this v0 implementation will be enabled and future work for Flakes that addresses its shortcomings may be handled by a Flakes SIG.
this would have extremely wide reaching effects and i’m sure different viewpoints. i don’t see why this is made as definite, let alone in the same phase as just beginning to create SIGs
another example is with
The
aux
CLI will be modified to provide more ergonomic management of packages and systems. Additional subcommands such asaux system switch
andaux system build
will be added to make onboarding and ongoing maintenance easier.
(disclaimer: i can totally get behind this feature btw)
which is yet another oddly specific detail i’m sure others would have different views on
my biggest concern after re-reading the roadmap with this comment in mind though? we don’t even have a clear path to governance
taking from phase 1:
This initial phase will involve an ad-hoc management structure due to its bootstrapping nature.
this is fine, makes sense
phase 2:
Like the Soft Fork phase, management structure will still be ad-hoc, but Committees, Special Interest Groups, and Working Groups may start to be formed.
ok so we may have a better way to make technical decisions, may not. i would hope for the former, but as you say, this will still be ad-hoc. maybe we take care of this before a hard fork…but ok, i can understand it
phase 3:
The packages repository will have sets extracted to allow for Special Interest Groups to more easily manage their lifecycles.
ok so SIGs will be a definite thing here, got it. the rest of this phase (called “organization”) doesn’t seem to have a lot of organization, though. there’s only this and the oddly specific technical decisions i quoted before
phase 4:
Now that the project has significantly diverged from upstream, we will need to provide our own Continuous Integration and Binary Cache services. Existing governance structures will be used to manage the adoption of these technologies.
here’s where i’m very concerned and a big reason why you shouldn’t be hesitant to change this roadmap. last i checked, our “existing governance structures” at this point should be SIGs with their own repositories, there may be committees and working groups, but (from phase 2) the management structure would still be “ad-hoc”. an “ad-hoc” management structure should not be making these long term decisions that would heavily affect the community either financially via donations or through how we’re represented to potential sponsors
and just for the record: i'm not trying to start a hate bandwagon here. these are just genuine issues i feel and i would like to see resolved before going further and investing more of my time. i would love to keep contributing and see this project grow - it's fun! - but it feels like we might be getting off on the wrong foot