• 5 Posts
  • 16 Comments
Joined 3 years ago
cake
Cake day: July 18th, 2021

help-circle
  • Either ranked-choice voting or majority judgement.

    Here's why

    Majority Judgment:

    1. Voters grade each candidate on a scale (e.g. Excellent, Good, Fair, Poor, Reject)
    2. The winner is determined by the highest median grade
    3. Ties are broken by measuring how many voters gave grades above and below the median

    Ranked Choice Voting:

    1. Voters rank candidates in order of preference
    2. If no candidate has >50%, the lowest-ranked candidate is eliminated
    3. Their votes transfer to those voters’ next choices
    4. Process repeats until someone has majority

    Majority Judgment optimizes for:

    1. Consensus/Compromise.

    By using median grades, it finds candidates who are “acceptable” to a broad swath of voters. A candidate strongly loved by 40% but strongly disliked by 60% will typically lose to someone viewed as “good enough” by most. This pushes politics toward centrist candidates who may not be anyone’s perfect choice but whom most find acceptable. The grading system lets voters express “this candidate meets/doesn’t meet my minimum standards” rather than just relative preferences

    2. Merit-based evaluation

    Voters judge each candidate against an absolute standard rather than just comparing them. This can help identify when all candidates are weak (if they all get low grades) or when multiple candidates are strong. It moves away from pure competition between candidates toward evaluation against civic ideals

    Ranked Choice Voting optimizes for:

    1. Coalition building

    By eliminating lowest-ranked candidates and redistributing votes, it rewards candidates who can be many voters’ second or third choice. This encourages candidates to appeal beyond their base and build broader coalitions. Unlike MJ, it’s more focused on relative preferences than absolute standards

    2. Elimination of “spoiler effects”

    Voters can support their true first choice without fear of helping their least favorite candidate win. This allows multiple similar candidates to run without splitting their shared base. The system is built around the idea that votes should transfer to ideologically similar alternatives


    Both systems optimize for honest voting more than plurality voting, but in different ways:

    MJ encourages honest evaluation because exaggerating grades can backfire if too many others don’t follow suit RCV encourages honest ranking because putting your true preference first doesn’t hurt your later choices

    The key philosophical difference is that:

    • MJ asks “What level of support does each candidate have across the whole electorate?”
    • RCV asks “Which candidate has the strongest coalition of support when similar preferences are consolidated?”

    This means MJ tends to favor broad acceptability while RCV tends to favor strong but potentially narrower bases of support that can build winning coalitions. Neither approach is inherently more democratic - they just emphasize different aspects of democratic decision-making. </details>


  • I’m generally skeptical of comments on the internet, so almost every time I have read comments like this one that you’re reading right now, I’ve been like “yeah right”. Kinda like how “lol” means “laughing out loud” but when you read it online you don’t really expect whoever wrote “lol” to have laughed out loud? Anyway, I was drinking coffee, I read your comment, I snorted in laughter, and now my white shirt is full of coffee.

    I guess I’m also kinda mad at myself for laughing so hard at such a silly joke. Regardless, have an updoot 👍







  • How do you choose what facts matter? How do you choose how to communicate them? Who do you communicate them to? What does news reporting mean to you? What about news reporting makes it worth your precious time alive? What purpose do the people around you have when they amplify, ignore, or quiet your facts? These are all questions that are answered, explicitly or not, by everyone who communicates or relates to facts.

    We could play the impossible “no agenda” game. We could lie to ourselves and to others. Or, we could notice that whenever we are dealing with the truth, we have a point of view. We stand here and not there. We can learn to travel around the mountain of truth, so that we mitigate our blindspots. We can be explicit about where in the mountain we are standing (The north base? The vegetated slope? The summit?).

    Instead of playing the “god trick”, we can situate our knowledge. That’s the best we can do. Check out this article by Donna Haraway on situated knowledge. It changed my life. https://philpapers.org/archive/harskt.pdf





  • I agree with you: the FSF can seem unwavering in their stance, even in the face of practicality. I’m really sorry for this incredibly nit-picky detail, but I think practicality is ideological too. For better or for worse, we can’t escape ideas or be free from them, so we have to choose which we value. For example, while I tend to choose software freedom over practicality, I also have, at times, chosen practicality over freedom.




  • I can see you’re frustrated by the downvotes and pushback you’ve received. It’s understandable to feel defensive when your viewpoint isn’t well-received. I appreciate you sharing your perspective, even if it goes against the majority opinion here.

    Your points about the space shuttle program’s challenges are valid and worth discussing. It’s important to note the timeframes involved though. The shuttle was developed in the 1970s, well before agile methodologies emerged in the 1990s and 2000s.

    Interestingly, one could argue that NASA may have used agile-like practices in the space shuttle program, even if they weren’t labeled as such at the time. However, I did a quick search and couldn’t find much concrete evidence to support this idea. It’s an intriguing area that might merit further research.

    Regarding modern agile approaches, while no method is perfect, many organizations have found them helpful for improving flexibility and delivering value incrementally. NASA’s recent use of agile for certain projects shows they’re open to evolving their methods.

    I’m curious to hear more about your thoughts on software development approaches for complex engineering projects. What do you see as the pros and cons of different methodologies? Your insights could add a lot to this discussion.



  • Your comparison is interesting, but let’s consider some historical facts. The Apollo program, which successfully put humans on the moon, actually employed many principles we now associate with Agile methodologies.

    Contrary to popular belief, it wasn’t a straightforward Waterfall process. NASA used frequent feedback (akin to daily Scrums), self-organizing teams, stable interfaces so that teams are an independent path to production, and iterative development cycles - core Agile practices. In fact, Mariana Mazzucato’s book Mission Economy provides fascinating insights into how the moon landing project incorporated elements remarkably similar to modern Agile approaches. Furthermore, here’s a NASA article detailing how Agile practices are used to send a rover to the moon: https://ntrs.nasa.gov/api/citations/20160006387/downloads/20160006387.pdf?attachment=true

    While it’s true that building rockets isn’t identical to software development, the underlying principles of flexibility, collaboration, and rapid iteration proved crucial to the missions’ success. Programs like the Apollo program adapted constantly to new challenges, much like Agile teams do today.

    Regarding Kanban and Scrum, you’re right that they fall under the Agile umbrella. However, each offers unique tools that can be valuable in different contexts, even outside of software.

    Perhaps instead of dismissing Agile outright for hardware projects, we could explore how its principles might be adapted to improve complex engineering endeavors. After all, if it helped us reach the moon and, decades later, send rovers to it, it might have more applications than we initially assume.