Nixpkgs Architecture Team | 233 Members | |
| https://github.com/nixpkgs-architecture, weekly public meetings on Wednesday 15:00-16:00 UTC at https://meet.jit.si/nixpkgs-architecture | 53 Servers |
| Sender | Message | Time |
|---|---|---|
| 5 Feb 2023 | ||
| * That may be true, but creating delegation slots for someone to be invited to step up doesn't seem like an a-priori risk. | 17:55:41 | |
| A little bit of push, to see if there is contributor market pull to organize around these topics while under the legitimacy and authority support of the NAT. | 17:56:42 | |
| Anyway, I'm not trying to sell any holy grale, I just have a sense thinking of ways to scale the positive impact of this team. | 17:57:35 | |
| * Anyway, I'm not trying to sell any holy grale, I just have a sense thinking of ways to scale the positive impact of this team is worth the conversation. | 17:57:52 | |
| * One such that just came to my mind while seeing this issue and this workaround would be a NAT Fetcher Chapter and maybe a NAT Package Chapter. | 17:58:23 | |
| But I fully understand that ownership is a precious and slow-to-build treasure. And currently there are only very few high profile ownerships of Nixpkgs. The reason may precisely be because we didn't manage to scale ownership in the past. | 18:00:03 | |
| Note, that some parts of the legitimacy and authority of the NAT are inherently scalable:
A coordination function could keep the lego pieces tightly joint. | 18:07:19 | |
| Ownership, in the right context, on the other hand, would I hold is infinitely scalable in human (& tech) society. | 18:10:28 | |
| * Ownership, in the right procreating context, on the other hand, would I hold is infinitely scalable in human (& tech) society. | 18:10:47 | |
| * Ownership, in the right incubating context, on the other hand, would I hold is infinitely scalable in human (& tech) society. | 18:11:08 | |
| * Ownership, in the right incubating context, on the other hand would I hold, is infinitely scalable in human (& tech) society. | 18:11:33 | |
| Yeah I'd also like more scalability at some point. Let's wait with this at least until the first RFC is complete though | 18:18:01 | |
| I could see this working e.g. by forming groups of people to work together on an RFC for nixpkgs, presenting the progress every week in the meeting and getting guided by the NAT | 18:21:11 | |
| These groups could be formed by people nominating themselves in issues from https://github.com/nixpkgs-architecture/issues/issues, nominations should probably include how much time per week one can help | 18:22:42 | |
| Some sort of reporting stream is probably a good start, and the breakout sessions for teaching & preaching. | 18:22:55 | |
| * Some sort of reporting stream is probably a good start, and then breakout sessions for teaching & preaching. | 18:23:07 | |
In reply to @infinisil:matrix.orgI think to break the damn (of market pull), a little bit of official push might be needed. But I also can't predict how easy it would be to mobilize and recruit future owners. | 18:24:18 | |
In reply to @infinisil:matrix.org* I think to break the dam (of market pull), a little bit of official push might be needed. But I also can't predict how easy it would be to mobilize and recruit future owners. | 18:24:41 | |
| * I think to break the dam (of contributor market pull), a little bit of official push might be needed. But I also can't predict how easy it would be to mobilize and recruit future owners. | 18:24:46 | |
| ⚖️ a little bit of push & a little bit of pull to see what happens 🤷 | 18:25:58 | |
| Ah true, maybe for a start it could be mentioned in the weekly discourse meeting notes how people can help out | 18:27:21 | |
| Very good idea, maybe coupled with a suggestion of strategic topics that the NAT has already in mind to help people match with their vocation. 🤷 | 18:28:35 | |
| * Very good idea, maybe coupled with a suggestion of strategic topics that the NAT has already in mind to help people make match with their vocation. 🤷 | 18:28:41 | |
| David Arnold (blaggacao): Honestly maybe that's how all RFC's should be done. Open an issue in the RFCs repository with an idea, have people nominate for working on the RFC together, once there's like 3 people, create a repository to develop it (RFC 138), requiring accepting reviews from each to change the repo. | 18:32:58 | |
| And another idea related to that: The shepherd team should be separate and be comprised of the code owners, they don't do the work, they only decide. This would be the NAT team for nixpkgs changes, the Nix team for Nix changes, etc. | 18:34:32 | |
The own repo work flow is excellent and very close to our all prefecence, you might have seen that I recently posted a link in discourse to frappe/gameplan. I'm still evaluating, but I have a gut feeling that this would maybe further improve our workflows as it increases not only theoric but practical transparency by consistently structuring the conversation. Anyway, just want to mention that in this context, but havn't made my mind up, yet. | 18:49:11 | |
* The own repo work flow is excellent and very close to our all prefecences. You might have seen that I recently posted a link in discourse to frappe/gameplan. I'm still evaluating, but I have a gut feeling that this would maybe further improve our workflows as it increases not only theoric but practical transparency by consistently structuring the conversation. Anyway, just want to mention that in this context, but havn't made my mind up, yet. | 18:49:24 | |
* The own repo work flow is excellent and very close to our all prefecences. You might have seen that I recently posted a link in discourse to frappe/gameplan. I'm still evaluating, but I have a gut feeling that this would maybe further improve our workflows as it increases not only theoric but practical transparency by consistently structuring the conversation. Anyway, just want to mention that in this context as a research question, but havn't made my mind up, yet. | 18:50:17 | |
* The own repo work flow is excellent and very close to our all prefecences. You might have seen that I recently posted a link in discourse to frappe/gameplan. I'm still evaluating, but I have a gut feeling that this would maybe further improve our workflows as it increases not only theoric but practical transparency by consistently structuring the conversation. Anyway, just want to mention that in this context as a research question, but haven't made my mind up, yet. | 18:50:22 | |
| This argument goes with the assumption that practical transparency is the most gentle and at the same time powerful push tactics of all, among other things. | 18:52:14 | |