Roadmap: Phase 1

hi all! first post here, but you might have seen some of my comments and PRs so far :stuck_out_tongue:

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 as aux system switch and aux 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
10 Likes

This is a very thoughtful write up and I am going to take some time to digest this. Thank you for writing it :pray:

6 Likes

A post was merged into an existing topic: The Future of Aux and Nix

Would you say this is a good TLDR? @getchoo

  • minimize tech decisions before governance
  • have community play a larger role in the roadmap

I agree especially with since really specific technical decisons (like “Flakes will be standardized with its current implementation as a v0”) that IMO don’t belong in a cant-be-edited plan. Also final stage saying “We have created a sustainable, independent fork […] Now […] first elections” seems to me like “now that all tech decisons have been made, let’s have an election”.

_

Ignoring tech (which I do think is important to keep setting up to maintain momentum), I think the governance phases could look something like:

  • just Jake
  • boot group (3 people, only meet if theres contention)
  • SIG groups and SIG core v1, treat SIG members as some kind of voting group
  • Establish “community” definition (v1) as direct democracy (separate from the SIG groups) who gets to vote (limit double-accounts risk)
    • We actually just ran into this as a problem for voting on a license and deciding that accounts created after a poll shouldn’t be allowed to vote in the community poll
  • Create a steering committee (v1), and designate what roles each (Committee, SIG groups, community) will play for different decisons
  • Re-hash some decisons like license, icon, repo name etc after this point

And I’m in favor of putting a bit more effort into the governance side, without stalling the tech deployment side.

3 Likes

Just coming back to this post - I’ve given it some consideration over the weekend and I’m at a point where I’d say I would be happy to considered for the committee, if members are still being looked for.

1 Like

100%

i actually just realized i left this part completely out in my original post, so thanks for bringing this up! i came to a similar conclusion after the more in-depth read i took of the roadmap for my original post.

the fact that this is a step after we have basically set up the project for long term is very concerning to me

i can get behind this. i feel it’s a much more tangible path to the currently (vague) roadmap, and importantly gets more people involved in making major decisions faster

  • Create a steering committee (v1), and designate what roles each (Committee, SIG groups, community) will play for different decisons

i will highlight this as the most important step in this plan, along with it’s placement. a major issue right now is that unlike this plan, a steering committee has already been created and added to with no input from the community

now as jake said in Consensus and Direction

I want to be clear that, currently, I am acting with the role of the Steering Committee in setting the direction for Aux. My goal in doing so is to make sure we follow through with the outlined roadmap, at which point an elected committee will take my place.

this sorta sounds like the “boot group” you describe. so as long as we aren’t making super drastic decisions, it should be fine
…but that’s not what’s happening here

as said in my original post, decisions have already been made from the beginning without community input, and attempts to give some have resulted in hesitance to change anything. this behavior has also continued with additions to this “boot group” steering committee (seemingly) being based solely on jake’s decision. furthermore, there has been no mention of these appointed members being replaced by an elected body – though my hope is that this was the intention, but it really should be made explicit

i would be more forgiving here and understanding, especially as the actions i just listed were taken before (as far as i can tell) any major issue was brought with how these things were being decided.

however, as of a few hours ago this behavior has continued in The Future of NixCPP: Lix. this is another example of huge technical decisions being made with no community input and brings much more concern to jake’s previous statement of

this alone made me feel as if jake might not be that hesitant towards changing the roadmap…as long as it’s something they personally want. after all, i don’t think someone extremely hesitant to change the roadmap across the board would drop what is quite literally the first thing mentioned in the first sentence of our roadmap

We will fork and maintain Nix, NixPkgs, and NixOS.

i really hope this is not the case of course, but it is hard to think otherwise based on these actions


now given all that, this leads me to your last point, jeff. i will have to disagree a bit

And I’m in favor of putting a bit more effort into the governance side, without stalling the tech deployment side.

the tech deployment side must be stalled at this point. as i just explained, these technical decisions are continuing to be made and seem to only be getting more fundamental in how the project will work in the long term. if we continue at the current pace with no proper governance to give the community a voice in these decisions, i honestly don’t see much future in what is meant to be a community project – as without us having a voice, what’s the point?

3 Likes

I’m mostly staying out of the political-social discussions because it’s not really my thing, but I’m a bit lost here. What technical decision has been made in the thread you’ve linked? The closest I can see is:

Which I just took to mean we don’t need to worry about nix dev if we don’t want to, rather than being a project decision. (Though I’m guessing many would agree that seeing how the Lix folks get on while we concentrate on more immediately pressing concerns is probably the way to go.)

1 Like

I actually agree with this. I personally see my position in the steering committee more as a way to help jake out. Since pretty much all I’ve been doing is inviting people to the org and helping manage. Which is why I’ve seen the steering committee more as a “boot group”. But i guess that’s not technically what it is.

2 Likes

I think the best place to start is to get the docs written up about what leadership means within aux. From there we can start holding elections, likely from a platform like loomio. We should also take into account all that we learnt from Voting and ensuring integrity.

4 Likes

I’m going to be honest here - I do find this to be mildly concerning. Personally, I would expect the Steering Committee to be a 100% collaborative effort, working together to decide on the direction of the project and gathering community input along the way. If the Steering Committee is essentially boiling down to “assisting Jake with administrative duties”, then I worry we might find our project’s direction being planned under an almost BDFL-like model - which I don’t think is the model we really want to be adopting in this project.

I don’t think this is the direction the Steering Committee intends to take, but I’m not sure how to interpret this other than a warning sign that things might start to veer off track. I do hope my fears here are unfounded, and we’re just going through early teething issues as the community is still very, very young and still developing it’s structure.

3 Likes

for starters, the title alone is saying lix is the future of cppnix. this implies that our fork is not

i guess this would be some careful wording, but given the context it doesn’t at all seem like it’s the intention.

for example:

emphasis on that last sentence. lix resolving this “entirely” heavily implies that the CLI sig will no longer be needing help in maintaining a cpp codebase (nix)

this is continued with

this continues the idea of us no longer maintaining a nix fork and moves that goalpost a bit to just a wrapper possibly

i would also like to note the topic this was posted in, which was the steering committee. i feel like if this was just a link to share, it would’ve been posted elsewhere. everything here - at least for me - seems to say “we are no longer forking nix” outside of the occasional “may” or “can”

if i am incorrect in this assumption though, i would like it to be explicitly stated. i’m very sure others in the community would also mistake a post like this in the steering community topic as a technical decision, rather than just a regular conversation about maybe dropping the idea of a nix fork

this also doesn’t address what may be a bigger issue here: the leader of this project quickly suggesting massive revisions to our roadmap after being “extremely hesitant” to any attempt from the community

3 Likes

Sorry, that was my bad. I was not clear, I shall do better next time. Now let me explain, when I was referring to my position I didn’t mean in the committee, i more meant as an admin of the forum and org.

As a member of the steering committee, my goal has always been to listen to the people. This has been the case ever since my post in call for maintainer, Call for Core Maintainers - #9 by isabel. And I don’t want anyone to feel overshadowed so I want posts like @getchoo and your own to keep coming to help us out, we take each one seriously and read them through. Just like I said here Adding Isabel to the Steering Committee - #2 by isabel.

Though If it is in the best interests of the community I will step down now, and we can have a discussion on whom we want to add to the committee.

2 Likes

I don’t think things are quite that bad yet. It’s nothing irreparable yet - I think the community just needs a little more transparency around what the intention of the Steering Committee is right now.

1 Like

I do feel this post was a bit of a knee jerk reaction to be the first person on the news. But I do agree with your points and the response should have been a bit more calculated.

this isn’t exactly what i had in mind. personally, i have no issues with you being on the sterring committee – i would probably even vote for you if we had one

i think a better solution would be to put the entire steering committee on hold for now; we shouldn’t have one if it’s not elected. instead, i think jeff’s plan with an explicit boot group (you still included) would be a much better idea. this would allow you to still assist jake in these early days (especially in getting to an actually elected committee), but also restrict any overly broad decisions to later down the line

3 Likes

I interpreted the steering committee as the boot group. But the way you put it I can understand where your coming from.

@jakehamilton can we get your thoughts on rebranding me and your position to a “boot group”. I quite like the idea seeing how that’s how I saw my position anyway. And considering at some point you mentioned your goal was only to get the fork started.

I’m curious on your thoughts on whether we should commit to a date to hold elections no matter what even if we are unready. I personally think not since we need to document the role of these positions.

3 Likes

i think a hard deadline would be unreasonable. these things take time to setup, especially for a project this young

obviously it shouldn’t be like 6 months from now or something that extreme, but as long as there is progress on the other steps in jeff’s plan and broad, long term decisions aren’t being made without any input? i think we could take our time here. it’s a big decision, and we all have busy lives outside of this i’m sure

1 Like

Yeah we (you and I) need to discuss how we can do things right here. We are only a week into Aux existing so things are still very new and thrown together. Much of the naming of groups is forward-thinking rather than accurately describing their function today. Separating into different groups is necessary right now and down the line the specifics of these groups will change. Things like SIGs and Committees will be more limited in numbers with non-members still contributing (and voting) via the leadership of those selected by the community to run it.

6 Likes

I’m going to very carefully suggest aiming for less governance right now. I know how that sounds, hear me out :sweat_smile:

I’m going to claim we have this shared experience: seeing the effect of no governance in Nix, and large projects with mature governance (e.g. Kubernetes). That’s making us very sensitive to not feeling listened to, and is making us reach for a lot of structure to compensate.

It’s only been a week. The sum of SIG and committee memberships is 62 people, less than 10% of nix or kubernetes (not counting the surrounding ecosystem, if we do then Aux is <<1%). We could still fit into one large conference room.

I’m worried about the excitement for radical changes: experiment with split nixpkgs structures, rewrite flakes, rip out flakes, p2p caching, switch forges and write all new CI machinery, etc. I think trying to design any of these with <1% of Nix’s people before we know if we can keep up with routine package maintenance will stall and end the project.

I would like to scope down: what governance do we need to build for the next, say, 2 months? In the short term I would like enough that we can collectively figure out how to make the routine maintenance of auxpkgs-placeholder-name-here sustainable given our resources, because if we can’t do that then what we’re building isn’t a nixpkgs fork, IMO.

I know that sounds like “lock in that big changes won’t happen”, but I don’t think that’s right. Our size makes fundamental changes cheap, at least for a while. Starting with “nixpkgs with a few more commits” is okay IMO, because switching to something else is a tractable amount of work. And by that I mean I volunteer to help execute those big changes, if/when we decide to.

With that in mind, a combo of @Jeff’s proposal and @jakehamilton’s original roadmap seems to work. Small appointed bootstrapping group in charge, with goals that are what’s already happening: organize volunteers to see what we’re working with, park accounts in various places, and set up tech to support further governance/communication (e.g. matrix, loomio, probably others).

I would like to add to that (but I defer to the bootstrap group) continuing the near 1:1 “soft fork” plan that exists, so that we can s/NixOS/aux-placeholder-name-here/ in our configs and start figuring out to make maintenance sustainable. I would like Aux to be an artifact I can use more ASAP, even if in 2 months I have to update my configs because of a breaking change.


Maybe this is a complete misreading of the forum’s vibe in the last few days, and I’m just projecting my own recent anxieties onto Aux’s bootstrapping. I abjectly apologise if so! Please assume all of the above is weakly held desires rather than demands, and I’m willing to put work into most directions that align spiritually with the fundamentals in auxioms, and output an OS that I can use :slight_smile:

15 Likes
  1. I want to gently correct this, as I currently see the steering committee and the boot group as the same thing. I asked for a boot group, and Jake was receptive and already added one person to it from my point of view. He’s also listened to the community on plenty of other things, like SIG groups elections, and Isabel was the head of core so it makes sense.

  2. Echoing a bit of what @danderson just said. IMO things are going at light speed right now. I asked to add two people with the expectation of that happening over weeks, not days. I’m pretty happy with Jake listening to the community. If anything it should slow down. Like I kind of wish the poll’s were open longer. (Speaking of which @isabel @srxl I’ve got a big half-done post SIG repos thread, but its going to be 48 hours before I can get back to it and finish it off)

  3. Think about the name. Sure it would be best to decide the name as a group, but we needed a discourse to rally around. And that Discourse needed a name. Its a lot easier to sit and critique than it is to take action and Jake deserves credit for being the change he wanted to see in the world. Every time I critique something I can always ask myself “why didnt I do it myself already if I care so much?”

  4. There is an important point of critique though, I do think Jake almost ad-hoc’d us into a giant mistake right there at the beginning, e.g. if Aux didnt brand itself as Auxolotl (big thanks to the oil-shell guy for swinging the tide on that issue). And that points us to the key thing: dont screw up the stuff that can’t be fixed later (naming, licensing), but dont be too tight about the tech decisons that can be reverted (hosting platform, clone vs inherit, splitting up based on ecosystem, etc).

3 Likes