I think a significant contributing factor is that management is a local maximum.
I am a self-identified "sort of knows what they are doing" (albeit, sometimes insecure about that) professional programmer. I've also had the chance to take a leadership position. So, I think I have a useful perspective here.
The amount "I" can accomplish in a leadership position is so much higher than by coding directly. So, on the margins, it's really hard to justify time spent coding, compared to coordinating others. It's incredibly easy to imagine stagnating as a coder due to not doing very much of it. Yet, clearly when everyone follows this route, software quality suffers. I don't have any particular solutions.
Perhaps eventually the rate of expansion of programmers will slow, and we'll end up with too many sort of knows what they're doing" programmers for everyone to move to management, so people/companies will start waiting until programmers hit the experienced mark to make the leap.
...Good! The "prompt" permission model is fundamentally broken, because all it does is train you to click through the prompt.
The "click the blocking button and turn it off" model is much better. It still trains you to turn off blocking when something is broken. However, crucially, that's only when it's broken. When it's not broken, you just use the site, instead of habitually clicking through the permission prompt that's just harvesting data, not actually needed to function.
And yes, malicious sites can of course display themselves as falsely broken until you grant the permissions. But this makes them more annoying to use, granting a UX edge to the honest sites which don't request unnecessary permissions. In other words, the incentives of sites and users are more aligned.
I recently wrote a SPA (in React) that, in my opinion, would have been better suited as a server-side rendered site with a little vanilla js sprinkled on top. In terms of both performance and development effort.
The reason? The other part of the product is an app, which is written in React Native, so this kept a similar tech stack. The server component is node, for the same reason. And the app is React Native in order to be cross-platform. We have ended up sharing very little code between the two, but using the same tech everywhere has been nice, in a small org where everyone does everything.
I have a friend who owns an Alexa, and this is the one use case I agree is very nice. I would buy a non-networked device with only this functionality, or an app (with no network permission) that does the same.
There's a similar discussion upthread where someone points out this is a matter of representation -- you could "unwind" the chess board into 1d just as easily.
The game starts with each player having 50 points "in the bank". In addition to moving normally, players may opt to move and split the timeline. If they split, they choose how many points to dedicate to the new timeline, which are put in its bank, distributed evenly between both players. Points must be whole numbers and each timeline must have at least 2 (max 50 timelines). Play continues normally on the original timeline, and they may opt to split again, if they have the points.
When a given timeline is played to checkmate, the winner secures all of their own and their opponent's points from that timeline. In the case of a tie, points are split evenly. First person to secure over 50 points wins.
The game keeps track of the history in each timeline. If one timeline's board enters a state that already occurred in a different board's history, both players are asked whether they'd like to merge timelines, in which case the banks from each timeline are combined and play continues on the board that is farther in the future.
The UI allows players to switch which timeline they are looking at freely So, both players can be playing at once, in different timelines. Initial implementation can show a single board at a time, a number showing which timeline you're viewing, how many points each player has banked in that timeline, and arrows for moving between timelines. Should be pretty easy to add, actually.
Competitive variant is timed. There is a single clock for each player, which counts down by the sum of all timelines in which it is their turn, scaled down by the % of total remaining points in that timeline.
That is, say we're playing 10+10 and there are currently two timelines, one with 20 points and one with 80. It's my turn in the 80 point timeline and yours in the 20 point timeline. While we wait here, my clock ticks down by .8 seconds per second, and yours by .2. Then I play. I gain +8 seconds, and my timer stops while yours starts ticking at full speed.
---
You'll note this isn't quite the original idea; a faithful implementation of that would have a shared pot of points that each player can split arbitrarily (including fractions of a point). But I didn't want to allow infinite splitting because that would make the game unplayably long (or, in timed variants, might lead to optimal strategies of overwhelming your opponent with many splits). And if infinite splitting is not allowed, then I don't want to allow one player to do all the splitting, that's no fun for the opponent.
The one thing I don't like is that this allows the stronger player to reliably win by never splitting and just winning the original board, since it will always have >50 points. This is probably fixable, not going to spend more time thinking about it right now though; this post has taken long enough :)
> There have been a few (tried Trello and ZenHub), and they've all turned into a mess, so I recently hit the reset button again and am just trying a github project now
In my experience, this is mainly caused by planning in too much detail, too far ahead. And then your plans change and it's a bunch of cl noise you have to clean up or live with.
The only system I've stuck with for my FLO projects is the following:
- One tag (or milestone) named "someday/maybe". This is for things that are reasonable to do (you'd accept patches), but not worth the time/effort for you to implement personally. It exists so you can filter them out without closing.
- One milestone called "next release". Only add issues to this milestone when you've competed them. Note: don't close these issues yet; keeping them open results in more visibility and fewer duplicate bug reports.
When it's time to do a release, rename the "next release" milestone to the version of the release (ex: v2.4.1), close all the associated issues (making sure they're in the changelog as you go), and replace it with a fresh "next release" milestone.
---
In the past I also had a "planned" milestone, but it's redundant with someday/maybe; anything open and not assigned to a milestone is planned.
Red Moon has the same order of magnitude of open issues as Buttplug, and not much of a community.
- If there were a larger community, I'd probably write a high-level roadmap, describing my vision and areas where it currently falls short.
- If there were other contributors or significantly more open issues, I'd add a "high priority" tag, limited to ~10 issues at a time, so there's a way to engage with less noise.
It feels like the automotive industry's product lines. Gradually increase the size and shift it more towards luxury, then introduce a new economy product line. Maybe in 2022 we'll get the iPhone XSE.