Looking for something to do at Contributor Day? We could use your help!
The Gutenberg Migration Guide is a crowdsourcing project to document WordPress Classic Editor customization points and their Gutenberg equivalents (if such exist). media_buttons is the quintessential example; whereas you might’ve used this action previously in the Classic Editor to register a button, it no longer exists in Gutenberg and the block inserter is its direct equivalent.
We want the migration guide to be as comprehensive as it can be. This is defined as:
Identifying as many integration points as we can find. For instance, there are already 14 actions / filters listed. Some are commonly used, while others are not. As long as we have a good example for how the integration point is used, it makes sense to include in the guide.
Whenever possible, documenting how feature parity can be achieved with Gutenberg. Some integration points do already have Gutenberg equivalents. Others don’t yet, and that’s alright.
You can help make the migration guide more comprehensive. If you don’t have any examples of your own to include, here are a couple of places you can start looking:
Everyone can contribute to the migration guide, regardless of skill set. All you need to do is open a new GitHub issue and report the incompatibility you’ve found. Screenshots and GIFs are tremendously helpful. If you know the underlying problem, then please include that too. If all you know is that a given plugin’s feature doesn’t work in Gutenberg, no worries; simply open an issue and we can help track down the cause. Identifying examples of breakage are what we need help with most.
Feel free to join #hosting-community in the WordPress.org Slack if you have any questions, etc. Thanks for your help!
Amazingly, our refrigerator doesn’t have an alarm for when you accidentally leave the door open.
In the last six months, we’ve left the refrigerator door open overnight three times. Because the light stays on when the door is open, another horrible design decision, the refrigerator thermometer hits 107°F by the time I notice it in the morning.
Using a Parallax Ping Ultrasonic distance sensor, the Arduino board detects its distance to the nearest object in front of it. If there’s nothing within 2 inches for greater than 5 seconds, then the Arduino board uses a piezo buzzer to make some noise. The system resets when an object is placed within 2 inches again.
On a whole, I was surprised how quickly I got up to speed on Arduino. My “Hello World” project, blinking a LED diode, took about 10 minutes to complete. This distance alarm only took 20 minutes beyond that, with a little bit of guidance on what hardware to use and access to tutorials on how to use it.
Up next: figuring out how to miniaturize the entire setup so I can put it in a small housing and deploy to production (aka use it in my home).
Although voting seems like an intuitive concept, there are a few major flaws that seem to be getting worse over time.
Voting is never truly representative
We assume voting is fair because it vaguely reflects some total population that we are trying to represent. It’s impossible to exactly pin down what “representative” means. (Similar demographics, interests, incomes, ideologies? All of the above?)
Voting is a competitive game
Voting is a zero-sum game, meaning that whomever wins does so at the expense of someone else. As a result, voting promotes competition, not cooperation. Players might coordinate as a means of gaining an edge (“if you vote for X this time, I’ll give you Y next time”), but ultimately, “winning” the vote means beating someone else.
So. We have our current system, and we’ve identified some emerging problems that we need to solve for. What does that look like?
Designing for cooperation, not competition
If you’re an avid board gamer, you’ve probably come across a cooperative game or two, like Pandemic or Forbidden Island. In a cooperative game, you work with, rather than compete against, your fellow players to achieve a shared outcome…
Open source is one of the most powerful, and underappreciated, ideas of our generation. Modern open source is about building and collaborating in public, not about the license. Most importantly, open source isn't conceptually limited to software development; it's most prevalent here because we have the correct tooling.
The other day, I was reading Tualatin City Council's work session materials for January 22nd (PDF warning). It's actually pretty interesting. Tualatin is considering a "Local Congestion Relief and Neighborhood Safety" bond measure, and the packet provides much of the background. But it's a PDF packet and I was only reading it because someone emailed it to me.
Which brings me to the three realizations I had:
Open source is Good™ because it increases collaboration. Increased collaboration means increased value creation. Ergo, civic engagement (and pretty much everything) would benefit from open source methodologies.
City data is really hard to come by. It needs to be manually collected and it's often out of date as soon as it's collected. Nowadays, any effort put into collection should result in a real-time, persistent data stream.
Cities should be learning from one another. Meaning, Tualatin must have a data profile similar to dozens of other cities in the US. If city A tries experiment B and it works, then we should use that knowledge as the basis of our evolution, infrastructure investments and otherwise.