All RPGs and Storygames by Tod Foley are now available at DrivethruRPG and RPGnow. Bring these games to your table!
Two weeks ago, I stumbled upon a two-part blog post by Alex Russell, titled Effective Standards Work.
It’s worth reading if you’re interested in how Drupal is developed, or in how any consensus-driven open source project works (rather than the increasingly common “controlled by a single corporate entity” “open source”).
It’s written with empathy, modesty and honesty. It shows the struggle of somebody given the task and opportunity to help shape/improve the developer experience of many, but not necessarily the resources to make it happen. I’m grateful he posted it, because something like this is not easy to write nor publish — which he also says himself:
I’ve been drafting and re-drafting versions of this post for almost 4 years. In that time I’ve promised a dozen or more people that I had a post in process that talked about these issues, but for some of the reasons I cited at the beginning, it has never seemed a good time to hit “Publish”. To those folks, my apologies for the delay.Parallels!
I hope you’ll find the incredibly many parallels with the open source Drupal ecosystem as fascinating as I did!
Below, I’ve picked out some of the most interesting statements and replaced only a few terms, and tadaaa! — it’s accurately describing observations in the Drupal world!
Go read those two blog posts first before reading my observations though! You’ll find some that I didn’t. Then come back here and see which ones I see, having been a Drupal contributor for >11 years and a paid full-time Drupal core contributor for >6.Standards Theory
Design A new Drupal contrib module is the process of trying to address a problem with a new feature. Standardisation Moving a contributed module into Drupal core is the process of documenting consensus.
The process of feature design Drupal contrib module development is a messy, exciting exploration embarked upon from a place of trust and hope. It requires folks who have problems (web developers site builders) and the people who can solve them (browser engineers Drupal core/contrib developers) to have wide-ranging conversations.
Feature Drupal module design starts by exploring problems without knowing the answers, whereas participation in Working Groups Drupal core initiatives entails sifting a set of proposed solutions and integrating the best proposals competing Drupal modules. Late-stage iteration can happen there, but every change made without developer site builder feedback is dangerous — and Working Groups Drupal core initiatives aren’t set up to collect or prioritise it.
A sure way for a browser engineer Drupal core/contrib developer to attract kudos is to make existing content Drupal sites work better, thereby directly improving things for users site builders who choose your browser Drupal module.
- Participation by web developers site builders and browser engineers Drupal core/contrib developers: Nothing good happens without both groups at the table.
- A venue outside a chartered Working Group Drupal core in which to design and iterate: Pre-determined outcomes rarely yield new insights and approaches. Long-term relationships of WG participants Drupal core developers can also be toxic to new ideas. Nobody takes their first tap-dancing lessons under Broadway’s big lights. Start small and nimble, build from there.
- A path towards eventual standardisation stability & maintainability: Care must be taken to ensure that IP obligations API & data model stability can be met the future, even if the loose, early group isn’t concerned with a strict IP policy update path
- Face-to-face deliberation: I’ve never witnessed early design work go well without in-person collaboration. At a minimum, it bootstraps the human relationships necessary to jointly explore alternatives.
If you’ve never been to a functioning standards Drupal core meeting, it’s easy to imagine languid intellectual salons wherein brilliant ideas spring forth unbidden and perfect consensus is forged in a blinding flash. Nothing could be further from the real experience. Instead, the time available to cover updates and get into nuances of proposed changes can easily eat all of the scheduled time. And this is expensive time! Even when participants don’t have to travel to meet, high-profile groups Drupal core contributors are comically busy. Recall that the most in-demand members of the group Drupal core initiative (chairs Drupal core initiative coordinators, engineers from the most consequential firms Drupal agencies) are doing this as a part-time commitment. Standards work is time away from the day-job, so making the time and expense count matters.
What I’ve learned over the past decade trying to evolving the web platform is a frustratingly short list given the amount of pain involved in extracting each insight:
- Do early design work in small, invested groups
- Design in the open, but away from the bright lights of the big stage
- Iterate furiously early on because once it’s in the web Drupal core, it’s forever
- Prioritize plausible interoperability; if an implementer says “that can’t work”, believe them!
- Ship to a limited audience using experimental Drupal core modules as soon as possible to get feedback
- Drive standards stabilization of experimental Drupal core modules with evidence and developer feedback from those iterations
- Prioritise interop minimally viable APIs & evolvability over perfect specs APIs & data models; tests create compatibility stability as much or more than tight prose or perfect IDL APIs
- Dot “i”s and cross “t”s; chartered Working Groups Drupal core initiatives and wide review many site builders trying experimental core modules are important ways to improve your design later in the game.
These derive from our overriding goal: ship the right thing.
So how can you shape the future of the platform as a web developer site builder?
The first thing to understand is that browser engineers Drupal core/contrib developers want to solve important problems, but they might not know which problems are worth their time. Making progress with implementers site builders is often a function of helping them understand the positive impact of solving a problem. They don’t feel it, so you may need to sell it!
Building this understanding is a social process. Available, objective evidence can be an important tool, but so are stories. Getting these in front of a sympathetic audience within a browser team of Drupal core committers or Drupal contrib module maintainers is perhaps harder.
It has gotten ever easier to stay engaged as designs experimental Drupal core modules iterate. After initial meetings, early designs are sketched up and frequently posted to GitHub Drupal.org issues where you can provide comments.
These relatively new opportunities for participation outside formal processes have been intentionally constructed to give developers and evidence a larger role in the design process.
There’s a meta-critique of formal standards processes in Drupal core and the defacto-exclusionary processes used to create them. This series didn’t deal in it deeply because doing so would require a long digression into the laws surrounding anti-trust and competition. Suffice to say, I have a deep personal interest in bringing more voices into developing the future of the web platform, and the changes to Chrome’s Drupal core’s approach to standards adding new modules discussed above have been made with an explicit eye towards broader diversity, inclusion, and a greater role for evidence.
I hope you enjoyed Alex’ blog posts as much as I did!
We're going on a two-week vacation in August! Believe it or not, but I haven't taken a two week vacation in 11 years. I'm super excited.
Now our vacation is booked, I'm starting to make plans for how to spend our time. Other than spending time with family, going on hikes, and reading a book or two, I'd love to take some steps towards food photography. Why food photography?
The past couple of years, Vanessa and I have talked about making a cookbook. In our many travels around the world, we've eaten a lot of great food, and Vanessa has managed to replicate and perfect a few of these recipes: the salmon soup we ate in Finland when we went dog sledding, the hummus with charred cauliflower we had at DrupalCon New Orleans, or the tordelli lucchesi we ate on vacation in Tuscany.
Other than being her sous-chef (dishwasher, really), my job would be to capture the recipes with photos, figure out a way to publish them online (I know just the way), and eventually print the recipes in a physical book. Making a cookbook is a fun way to align our different hobbies; travel for both of us, cooking for her, photography for me, and of course enjoying the great food.
Based on the limited research I've done, food photography is all about lighting. I've been passionate about photography for a long time, but I haven't really dug into the use of light yet.
Our upcoming vacation seems like the perfect time to learn about lighting; read a book about it, and try different lighting techniques (front lighting, side lighting, back lighting but also hard, soft and diffused light).
The next few weeks, I plan to pick up some new gear like a light diffuser, light modifiers, and maybe even a LED light. If you're into food photography, or into lighting more generally, don't hesitate to leave some tips and tricks in the comments.
The other day I was working on some sample code to test out an idea that involved an object with an internal nested array. This is a pretty common pattern in PHP: You have some simple one-off internal data structure so you make an informal struct using PHP associative arrays. Maybe you document it in a docblock, or maybe you're a lazy jerk and you don't. (Fight me!) But really, who bothers with defining a class for something that simple?
But that got me wondering, is that common pattern really, you know, good? Are objects actually more expensive or harder to work with than arrays? Or, more to the point, is that true today on PHP 7 given all the optimizations that have happened over the years compared with the bad old days of PHP 4?
So like any good scientist I decided to test it: What I found will shock you!
The goal of the value module is to make field values easily accessible inside Twig templates.
So obviously, the pendulum of progress stopped swinging on my game. As much as I tried to prevent it, pressing obligations just wouldn’t take a back seat (nor would the burglars who, a few weeks ago, stole 90% of my wardrobe and who last week stole my monitor). So after a string of hectic weekends and even crazier weeks, this weekend has been pretty wide open for doing whatever I want to do. And not a moment too soon!
So after doing all the other things I try to do with my weekends, I finally loaded up the ol’ Inform 7 IDE and started working on my game. To get me back in the swing of things, so to speak, I started reading through what I’d already written. It was an interesting experience.
Strangely, what impressed me most was stuff I had done that I have since forgotten I learned how to do. Silly little things, like actions I defined that actually worked, that had I tried to write them today, probably would have had me stumped for a while. Go me! Except, erm, I seem to have forgotten more than I’ve retained.
I also realized the importance of commenting my own code. For instance, there’s this snippet:
A thing can be attached or unattached. A thing is usually unattached. A thing that is a part of something is attached.
The problem is, I have no idea why I put it in there – it doesn’t seem relevant to anything already in the game, so I can only imagine that I had some stroke of genius that told me I was going to need it “shortly” (I probably figured I’d be writing the code the next night). So now, there’s that lonely little line, just waiting for its purpose. I’m sure I’ll come across it some day; for now, I’ve stuck in a comment to remind myself to stick in a comment when I do remember.
It reminds me of all the writing I did when I was younger. I was just bursting with creativity when I was a kid, constantly writing the first few pages of what I was sure was going to be a killer story. And then I’d misplace the notebook or get sidetracked by something else, or do any of the million other things that my easily distracted self tends to do. Some time later, I’d come across the notebook, read the stuff I’d written and think, “Wow, this is great stuff! Now… where was I going with it?” And I’d never remember, or I’d remember and re-forget. Either way, in my mother’s attic there are piles and piles of notebooks with half-formed thoughts that teem with potential never to be fulfilled.
This situation – that of wanting to resume progress but fumbling to pick up the threads of where I left off – has me scouring my memory for a term I read in Jack London’s Call of the Wild. There was a part in the book where Buck’s owner (it’s late, his name has escaped me) has been challenged to some sort of competition to see if Buck can get the sled moving from a dead stop. I seem to remember that the runners were frozen to the ground. I thought the term was “fast break” or “break fast” or something to that effect, but diligent (does 45 seconds count as diligent?) searching has not confirmed this or provided me with the right term. Anyway, that’s how it feels tonight – I feel as if I’m trying to heave a frozen sled free from its moorings.
The upside is, I am still pleased with what I have so far. That’s good because it means I’m very likely to continue, rather than scrap it altogether and pretend that I’ll come up with a new idea tomorrow. In the meantime, I’ll be looking for some SnoMelt and a trusty St. Bernard to get things moving again.
So I didn’t get as much coding done over the weekend as I had hoped, mainly because the telephone company *finally* installed my DSL line, which meant I was up til 5:30 Saturday am catching up on the new episodes of Lost. That, in turn, meant that most of the weekend was spent wishing I hadn’t stayed up until such an ungodly hour, and concentration just wasn’t in the cards.
However, I did get some stuff done, which is good. Even the tiniest bit of progress counts as momentum, which is crucial for me. If the pendulum stops swinging, it will be very hard for me to get it moving again.
So the other day, as I was going over the blog (which really is as much a tool for me as it is a way for me to share my thoughts with others), I realized I had overlooked a very basic thing when coding the whole “automatically return the frog to the fuschia” bit…
As the code stood, if the player managed to carry the frog to another room before searching it, the frog would get magically returned to the fuschia. This was fairly simple to resolve, in the end – I just coded it so that the game moves (and reports) the frog back to fuschia before leaving the room. I also decided to add in a different way of getting the key out of the frog – in essence, rewarding different approaches to the same problem with success.
Which brings me to the main thrust of today’s post. I have such exacting standards for the games I play. I love thorough implementation. My favorite games are those that build me a cool gameworld and let me tinker and explore, poking at the shadows and pulling on the edges to see how well it holds up. A sign of a good game is one that I will reopen not to actually play through again, but to just wander around the world, taking in my surroundings. I’ve long lamented the fact that relatively few games make this a rewarding experience – even in the best games, even slight digging tends to turn up empty, unimplemented spots.
What I am coming to appreciate is just how much work is involved in the kind of implementation I look for. Every time I pass through a room’s description, or add in scenery objects, I realize just how easy it is to find things to drill down into. Where there’s a hanging plant, there’s a pot, dirt, leaves, stems, wires to hang from, hooks to hang on, etc. Obviously, unless I had all the time in the world, I couldn’t implement each of these separately, so I take what I believe to be the accepted approach and have all of the refer to the same thing. Which, in my opinion, is fine. I don’t mind if a game has the same responses for the stems as it does for the plant as a whole, as long as it has some sort of relevant response. Even so, this takes a lot of work. It might be the obsessive part of me, but I can’t help but think “What else would a person think of when looking at a hanging plant?”
Or, as I’ve come to think of it: WWBTD?What Would Beta Testers Do?
I’ve taken to looking at a “fully” implemented room and wondering what a player might reasonably (and in some cases unreasonably) be expected to do. This is a bit of a challenging process for me – I already know how my mind works, so trying to step outside of my viewpoint and see it from a blind eye is hard. I should stop for a second to note that I fully intend to have my game beta tested once it reaches that point, but the fewer obvious things there are for testers to trip over, the more time and energy they’ll have for really digging in and trying to expose the weaknesses I can’t think of.
I’ve found one resource that is both entertaining and highly informative to me: ClubFloyd transcripts. ClubFloyd, for the uninitiated (a group among which I count myself, of course) is a sort of cooperative gaming experience — if anyone who knows better reads this and cares to correct what may well be a horrible description, by all means!– where people get together on the IFMud and play through an IF title. The transcripts are both amusing and revealing. I recently read the Lost Pig transcript and it was quite interesting. The things people will attempt to do are both astonishing and eye-opening. In the case of Lost Pig (which, fortunately, I had already played before reading the transcript), what was even more amazing was the depth of the game itself. I mean, people were doing some crazy ass stuff – eating the pole, lighting pants on fire, and so on. And it *worked*. Not only did it work, it was reversible. You obviously need the pole, so there’s a way to get it back if, in a fit of orc-like passion, you decide to shove it in down Grunk’s throat.
Anyway, my point is, the transcripts gave me a unique perspective on the things people will try, whether in an effort to actually play the game, to amuse themselves, or to amuse others. Definitely good stuff to keep in mind when trying to decide, say, the different ways people will try to interact with my little porcelain frog.Other Stuff I Accomplished
So I coded in an alternate way to deal with the frog that didn’t conflict with the “standard” approach. I also implemented a few more scenery objects. Over the course of the next few days, I’m going to try to at least finish the descriptions of the remaining rooms so that I can wander around a bit and start really getting to the meat of it all. I also want to work on revising the intro text a bit. In an effort to avoid the infodumps that I so passionately hate, I think I went a little too far and came away with something a bit too terse and uninformative. But that’s the really fun part of all of this – writing and re-writing, polishing the prose and making it all come together.
Whattaya know. Midnight again. I think I’m picking up on a trend here.
Grrr… I’ve been so bogged down in work and client emergencies that progress on the game is at a temporary (no, really! Only temporary) standstill. I’ve managed to flesh out a few more room and scenery descriptions, but have not accomplished anything noteworthy in a few days. Hopefully after this week most of the fires on the work front will be extinguished, and I’ll have time to dive into the game this weekend.
(She says to no one, since there’s been one hit on this blog since… it started.)