Hacker Newsnew | past | comments | ask | show | jobs | submit | ims's commentslogin

'mjwhansen founded the Small Software Business Alliance specifically to work on this issue: https://ssballiance.org/


Seems like the existing user base, reviews, and lists were the main source of value. I don't want to be "that guy" but I'm curious what made it so hard to rewrite some or all of the CRUD aspects?


This guy is a straight-shooter with upper-management written all over him.


Technical people love parliamentary procedure because it notionally resolves messy human deliberation into a linear call stack with system interrupts.

The important thing to understand is that the rules are mainly for exception handling and are borderline irrelevant on the golden path. Most of the time, committees don't even think about the rules because everyone understands motions, seconding, and voting. Groups often operate in de facto ‘suspension of the rules’ and just talk through issues semi-formally until it’s time to take a vote. That’s actually the optimal outcome in most settings.

The true test of the rules is when disagreements arise about the form of debate rather than subject matter. Sometimes there is a legitimate procedural question but often this comes up when the apparent minority decides to start maneuvering because they believe they are going to lose. In the real world, this tends to play out in one of two ways depending on context:

1. This is a highly professional body with a parliamentarian at the meeting (or at least somebody plausible like a general counsel) who can call the balls and strikes, or the chair is—at least in principle—considered competent to rule by enough people present. A ruling is made and the body moves on.

2. This is an amateur body (which includes most government bodies below the state/province level and the vast majority of private committees/panels/boards), in which case people will resolve the issue as humans usually do. Namely, either the meeting will fall apart and be unable to conduct business or the most influential or aggressive parties will win regardless of what the rules say.

"But the body can just resolve everything properly by reading the rules!" -- well, theoretically.

But think back to the last time you played one of those byzantine German board games for the first time. Now imagine that nobody at the table really cares about board games and are not used to reading game rules. Further imagine that some parties are willing to defect from the spirit of the rules in order to raise esoteric legal and procedural objections, waste time, and filibuster outcomes they don’t want.

Real meetings have time limits, and while the U.S. Senate might stay up past midnight occasionally, regular people who have to wake up for work in the morning and who are giving up family time for a thankless volunteer position generally will not tolerate taking 5 hours to unwind the call stack in a hostile proceeding. So again, the loudest and most assertive parties tend to wear everyone else down. In that case the rules are at best useful for establishing in the record that procedure was not followed, which is only really useful if the issue can be escalated to the courts, appealed to a higher body, or revisited in a subsequent session.

Others in the thread have suggested simplified rulesets, and I’ll recommend Rosenberg’s Rules of Order which was designed by an experienced judge specifically for smaller meetings. But the truth is that almost any set of rules will work for amateur bodies if parties operate in good faith, and almost no set of rules will work if not.


Fascinating. Have you written about your experience there?


Yeah, I want to be there for the podcast/article/blog too…


Have you looked at RocksDB? http://rocksdb.org/


DrivenData Labs | Data Scientist and Senior Data Scientist | Berkeley, CA / Boston, MA / Denver, CO | REMOTE | Full-time

We run online machine learning challenges with social/scientific impact, and we work directly with mission-driven organizations on all sorts of interesting data science consulting projects. Since 2014 we’ve worked with more than 50 organizations in areas like international development, health, education, research and conservation, and public services.

We pride ourselves on being a great place to work and to learn. We take the development of our team members very seriously and we value the priorities that we each have in our lives at work and outside of work. We help each other develop clean, well-organized, well-documented code in service of correct and reproducible data science.

Our team writes and speaks often about reproducible data science and data ethics -- you may recognize our Cookiecutter Data Science project (https://drivendata.github.io/cookiecutter-data-science/) or the Deon data ethics checklist (https://deon.drivendata.org/).

We're looking for more great people in Boston, the Bay Area, or any of the states we currently operate. Feel free to reach out with any questions: isaac@drivendata.org

Positions: https://drivendata.workable.com/


Sounds like you're looking more for optimization theory, but if you want a gentle introduction to applications with approachable math and lots of examples, I highly recommend "Operations Research: Applications and Algorithms (4E)" by Wayne Winston. It's a solid undergrad level text covering basic linear optimization, mixed integer linear programs, and non-linear optimization.


As far as storing a human readable version for code reviews and diffs, we use nbautoexport for this - https://nbautoexport.drivendata.org/ - which automatically exports plain text source files.

(Disclaimer: this tool was written and maintained by colleagues of mine.)


This tool looks cool. Unfortunately, it looks like this tool in export-only. Ideally, one wants a single source of truth, and if your reviewed artifacts can't be imported for execution, then your code review can't be reviewing your source of truth. Don't get me wrong: it's much better than reviewing JSON diffs, but in highly regulated/conservative industries, we'd prefer to be reviewing the actual code that gets compiled/interpreted.


I think the user vs. product dichotomy is not right in this case. Microsoft really does make its money on products and support. You can see this on their public filings.

The relevant dichotomy is more like: people who run Windows aren't the buyers. One-off personal licenses for home PCs are more than a rounding error but are certainly not what made Microsoft what it is.

Governments and F500 companies buy Windows and Office for X00,000 machines for X0 years of support at a time. Enterprise procurement teams are the actual buyers whose opinions matter to product managers.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: