Roadmap: Phase 1

[jakehamilton]

Today we begin Phase 1 of our roadmap, the Soft Fork:

This initial phase will involve an ad-hoc management structure due to its bootstrapping nature. As such, the project’s stated Values, Goals, and Roadmap serve to keep all contributors aligned and safe knowing that the work they have committed to will not change.
The initial forking off of Nix and NixPkgs will be performed in this phase and new contributors will be given roles for handling package maintenance and pulling changes from upstream. We intend to move on from this phase once enough contributors have joined for the project to be capable of transitioning into a hard fork.

To be added to the organization, please use the following topic: GitHub Organization Membership

[Jeff]

Could I get a link to the roadmap? I had it somewhere but now I can’t find it in the Discourse or on google.

[liketechnik]

I thinks that’s the one at aux.computer (at the bottom of the page)

[jakehamilton]

@liketechnik is correct that it is on https://aux.computer

[isabel]

@jakehamilton you forgot the Sig go team on github

[jakehamilton]

My attempts to destroy Go have been foiled again!

(thank you for letting me know)

[jakehamilton]

As a part of Phase 1, reponsibility for the Soft Fork is being delegated to @sig_core. If you would like to help, please consider joining the group!

Soft Fork Maintenance

I will be delegating responsibility and authority over managing the NixPkgs soft fork to the core team here. The goals during this phase are: Limited amount of customization to reduce the overhead necessary for pulling in changes from upstream Staying up to date with upstream NixPkgs Establishing familiarity with the forked package set Noting any pain points that make this phase difficult @sig_core should now organize to best collaborate in order to achieve these goals.

Call for Core Maintainers

Reason: I’ve already signed up as a volunteer for the Rust-SIG and seeing as core maintainers are also sought for, I definitely can imagine helping here. Experience: Most of the things from here apply here too. In addition to far-reaching Rust experience and being a nixpkgs contributor all over, I do have my fair share of experience with the languages (i.e. C and C++) used by most core packages in (nix)pkgs as well, so that’s no hurdle at all for me. I’m familiar with Arch and Debian packaging …

[Jeff]

Thanks! Thats what I couldn’t remember.

I do want to say, I think the bootstrapping could be more democratic and a bit more clear. I know bootstrapping is messy, I just want to help reduce the mess to make sure we dont hit any snags with the momentum.

• Phase 0: I think you @jakehamilton should pick 2 active people that you trust to add to a bootstrapping group. I say group not committee because I dont think you guys should meet or vote, executive actions will still be pretty much everything, but having more than one person for any bootstrapping steps that become a point of contention seems important.
• In terms of clarity; for the phases answer stuff like:
  • How will decisons be made during this phase?
    • “At first Jake will make all decisions by listening to community feedback on the Discourse”
  • What will NOT be done in phase1?
    • Establish a steering committee
    • Naming of things like the OS (only placeholder names)
  • What needs to be done for phase1?
    • create a discourse
    • decide on communication medium(s)
    • identify willing maintainers
    • create an organization
    • decide where to host code
    • reserve “aux” name on various sites
    • …
  • Phase2
    • How will decisons be made?
    • What will not be done:
      • finalize a repo structure (maybe idk)
    • What will be done:
      • Answer: will the CLI be forked aux-env
      • Answer: will the auxlib be a git fork or just import nixpkgs
      • Answer: are all the nix repos (ex: patchelf) going to be forked or just nixpkgs/nixos
      • Answer: is the website going to be forked/hosted

Etc

It’ll definitely need editing/updating as things evolve, so maybe it would be easier to have the roadmap in a thread in discourse.

As a side note: I think “reannoucement of Aux” should be somewhere and maybe on there multiple times. JonRinger, who was at the epicenter of all this still hadn’t heard of Aux! And he might be one of the biggest contributors and best people to help shape the bootstrapping steps.

[jakehamilton]

I’ve been thinking on this for the last few days, I’m glad you’ve written this out.

For managing the bootstrapping process and making decisions I have been thinking about how this could be done quickly, reliably, but with more input. I had come to pretty much the same conclusion: bring two additional members into the steering committee. It would still be a small committee right now, focused around tight communication and moving the project forward. If anyone is interested, please let me know.

For modifying the roadmap, this is something I am extremely hesitant to do. The reason for posting the values, goals, and roadmap was to outline exactly what would happen during the initial stages of the project during the time where governance wouldn’t fully be there. This way everyone who wants to contribute can be confident that things won’t shift out from under them before elections happen. Perhaps additional details or clarifications are necessary, but I would prefer not to modify the existing limited roadmap.

And in regards to Jon Ringer: he is aware of Aux, but as described in this answer he may not be a good fit for the project

Aux.computer - an alternative to the Nix ecosystem

[marshmallow]

JonRinger, who was at the epicenter of all this still hadn’t heard of Aux! And he might be one of the biggest contributors and best people to help shape the bootstrapping steps.

There has been a blissful lack of trolls so far and it would be cool if it stayed that way…

[Jeff]

@jakehamilton

If anyone is interested, please let me know.

I would be, except I’m at risk of dissapearing for weeks at a time. I usually contribute in concentrated bursts, because I have my interests spread over too many things to have a persistent contribution to all of them. (Actually its also why I need nix; I can’t afford for my code to bitrot when I come back to it after a year or two.)

So if

1. Theres a role where that isnt a problem, or
2. If theres an “emergency contact” roll, where I can give my phone number and basically be on-call in the event that theres an important impass in the community

I could probably do that. But outside of that, I don’t want to commit to a role I can’t put the proper focus into.

[Jeff]

@jakehamilton

For modifying the roadmap, this is something I am extremely hesitant to do.

I’m glad you’re hesitant. But in terms of modification

1. I think theres a way to do it where me you and others find that no goalposts are being moved and no promises are being broken
2. But also, I don’t think we have a choice in the matter. Like, humans are not skilled enough to one-shot a long multi stage plan and expect to get it right first try. New information and perspectives will arrive with time, and should cause things to be reconsidered.

Principles can stay the same, while actions change. But I think its important to have tangible actions on a roadmap instead of just some abstract set of principles.

An incomplete but actionable rule right now could be: only add detail to the roadmap so that theres no moving of existing goalposts. That means we’ll need to be extra careful, but at least it provides some room for modification.

[dfh]

@jakehamilton

If anyone is interested, please let me know.

Would love to participate in the process. I’ve currently got regular time on my hand and feel a lot of excitement about this project.

[srxl]

I may be interested in participating in steering committee activities. I’ll need some time to consider if this is a responsibility I should be picking up at the moment, though - if someone else expresses interest before I’ve made a decision on this one, feel free to consider them first.

[getchoo]

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

@jakehamilton

For modifying the roadmap, this is something I am extremely hesitant to do.

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

@jakehamilton

The reason for posting the values, goals, and roadmap was to outline exactly what would happen during the initial stages of the project during the time where governance wouldn’t fully be there

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

[jakehamilton]

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

[Jeff]

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.

[srxl]

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.

[getchoo]

@Jeff

Would you say this is a good TLDR? @getchoo

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

100%

@Jeff

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”.

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

@Jeff

• 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

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

@jakehamilton

For modifying the roadmap, this is something I am extremely hesitant to do. The reason for posting the values, goals, and roadmap was to outline exactly what would happen during the initial stages of the project during the time where governance wouldn’t fully be there. This way everyone who wants to contribute can be confident that things won’t shift out from under them before elections happen.

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?