The level of trust required is immense. We’re talking about a position where you get the keys to the kingdom to a very large number of projects
I would say that having roadie level access is equivalent to having access to Django core. I have never seen a recent Django project that isn’t pulling something from jazzband
Despite this I think it’s important to highlight that even in that world jazzband had a lot of infra so that projects could do things like releases cleanly and safely (we aren’t doing direct project releases to pypi but going through jazzband infra to do the release). So release maintainers have a lot less access despite releases “coming from” Jazzband
Why are we assuming that there were lots of volunteers in the first place? If this is such a high-trust position, it should be called something other than "roadie". I thought it was common knowledge that the term "roadie" is considered mildly derogatory, and that the modern word was more specific and skill-based, i.e. "stage manager", etc.
As an N=1 example, I myself have some experience with various Django packages including some Jazzband ones. Around 7 years ago I looked at this organization, thought about volunteering to be a "roadie", and specifically decided not to do so due to the terminology. I'm pretty sure that something like "Looking for trusted co-maintainers with a history of FOSS contribution" would draw in more folks than "Looking for roadies".
If you're going to say "well no one complained", guess what, I didn't either. People will just quietly decide to not volunteer due to stuff like this; leading to a shortage over time.
Summary: Branding and acknowledgement matters, so check carefully what you call the volunteers that you're expecting tens of hours of free work from.
That requires a lot of infra that isn’t built into _any_ of our tooling.
It’s not so much about decision making as it is about the practical reality that people at that level basically need at least read access to a lot of secrets.
You could say “maybe jazzband can infra its way out of those problems” but that’s a looooot of work! “N out of M consensus on making a GitHub API request to set who is a maintainer” * every single action roadies need to do
It’s not just about bad actors either. Imagine a jazzband roadie getting credentials stolen via some npm-y attack. Obviously this problem exists in the project in the current form but _that problem gets worse just onboarding people_
> maybe jazzband can infra its way out of those problems
Maybe jazzband can't infra their way out of the problem, but maybe we can create some tools that will help orgs that encounter this problem in future...
... that's a software engineer in me talking. I have no idea how to organize communities, but I may know a thing or two about making software. And when you've got a hammer in your hands everything starts looking like a nail...
yeah tbqh I think the biggest challenge with tooling on that front is that this really is a problem mostly limited to community projects. The problems jazzband need to solve don't exist nearly as much in a universe where everyone is in a company on some payroll
In most corporate environments while it might make sense to do N of M in the high security case it's not really a thing that people will jump for for the first... uhhh 10k employees of a company's lifetime.
This stuff stands on the foundations it's built off of. It's very hard to argue against the stoic determinism of an `ls` call.
And all the success stories I've seen in people using these tools have had a similar theme: top level might be LLM-y but you rush to get to deterministic straightforward building blocks so that you can have reliability.
That, to me, looks like writing up a bunch of small programs to help establish vocabularies and workflows to avoid just churning and getting lost in the weeds.
I'd be interested in seeing some future form of process orientation, but in the meantime.... shells in general have proven they are decently good at tying stuff together quite well.
`ls dir | grep thingy | process` gonna involve less possibility of annoying drift and churn than "run process on all the files with thingy in their name in directory"
tbqh I think one can survive with a merely decent trackpad on a bus or at meetings.
I've dual run Macbooks and Thinkpads for a while and the Thinkpad trackpad really isn't that bad (the trackpoint getting randomly stuck in a non-neutral position is a common thing I've experienced though)
The nicest thing for the Macbook for me in practice (disclaimer: I don't do fancy things on the trackpad) is the size. It "feels" fancier but the thinkpad plastic works totally fine for me.
I think some Mac users overindex on the quality of like... $400 Acer laptops from 2008 or whatever as their metric for "cheap Windows laptop".
Software stuff is still garbage but lots of machines have just straightforwardly decent hardware. Apple hardware is _very very good_ but it's not like the bad old days of "I actually cannot use this trackpad" in windows land. As much
I still can't get over how this thing is priced the same as the 2013 Macbook Air... when looking at JPY prices.
I wonder how much of the Neo pricing wow factor is Apple taking advantage of the strong dollar vs much else that's changed on the ground (obv the processor pick is a "real thing")
Well the Macbook Air pricing in USD was always around $1000 right?
2013 MBA pricing in USD was $1100
2013 MBA pricing in JPY was 110k JPY
2026 Macbook Neo pricing in JPY is ~100k JPY
2026 Macbook Neo pricing in USD is $600
2026 Macbook Air pricing in JPY is ~140k JPY
2026 Macbook Air pricing in USD is ..~$1100
So depending on the currency either the Neo is a massively cheaper thing or filling a gap in a product line that inflation created.
I wonder how much of Apple's costs are USD-denominated. The fact that the MBA hasn't changed pricing at all makes me guess that not that much, but I don't know how manufacturing contracts work
I dunno, I find it interesting, but JPY inflation is a recent phenomenon
Apple has a different relationship with the Paradox of Choice than most companies. The price stability makes it a bad idea generally to buy the old model right when the new one comes out. And not chasing inflation numbers I think is also part of that.
They also have some of the highest margins on consumer electronics in the business. Higher IIRC than Nokia had, before smartphones killed them. So absorbing a 3% bump in the dollar isn't that big a deal for them.
That’s probably fair which is why I tried to be upfront that this is shilling. I figure some people might be like me, interested in sprites but not artsy enough to make them. You might start with an ai sprite and fix it via LibreSprite or another tool.
It feels like we're fairly close yet so far. Lots of newer tools do have animation and tweening of arbitrary properties but then will just have bitmap image editors instead of a built-in vector editor for example. Or just make it really hard to tie all the stuff together.
The ease at which Flash CSx would just let you draw a circle in a spot, then click on it to get its script file and immediately add a little bit of behavior is magic for prototyping
I mean it's possible for there to be bad health effects from something without it outright killing everyone. This is why things like hygiene are tough! You can have terrible hygiene and still be alive for a long time.
Perhaps if Sweden adopted a different policy it would have an even longer life expectancy!
> Perhaps if Sweden adopted a different policy it would have an even longer life expectancy!
The policy of being between 55 and 69 N? I'm not sure the world is ready for another viking age.
Joking aside, GPs point was that Sweden has long nights and long days. Based on the studies you'd expect life expectancy to be worse there than in more Southern parts, like most of Canada. It isn't.
The Django admin is really great. I do wish there could be a bit more extensibility hook points to hook into existing stuff, but I know a loooot of projects that hack stuff into the admin despite that (I think in particular it's a bit futzy to have things like confirmation screens on custom actions).
I think the real power of Django comes from not only having the batteries included, but almost always having the right kind of extension points in terms of methods (or template overrides) that really give you ways to quickly insert the right kinds of customization for your project. The admin existing and working so well for so long is proof of that IMO
If you work with Django long enough, and at significant scale, you live long enough to b̶e̶c̶o̶m̶e̶ ̶t̶h̶e̶ ̶v̶i̶l̶l̶a̶i̶n̶ make hacky extensions to the admin.
I am hoping this work makes it easier for people to start extending the admin in a normalized way.
I would say that having roadie level access is equivalent to having access to Django core. I have never seen a recent Django project that isn’t pulling something from jazzband
Despite this I think it’s important to highlight that even in that world jazzband had a lot of infra so that projects could do things like releases cleanly and safely (we aren’t doing direct project releases to pypi but going through jazzband infra to do the release). So release maintainers have a lot less access despite releases “coming from” Jazzband
reply