A WordPress without Woman.

If WordPress had no Woman contributors, 4.7 wouldn’t have had a release lead.
If WordPress had no Woman contributors, The queue for plugin reviews would rarely be empty.
If WordPress had no Woman contributors, many WordCamps would lack lead organizers, speaker wranglers and sponsor wranglers.
If WordPress had no Woman contributors, most WordCamps never would have been approved to be organized.
If WordPress had no Woman contributors, The REST-API never would have made it into core.
If WordPress had no Woman contributors, WordPress for Dummies never would have been written.
If WordPress had no Woman contributors, many support questions would go unanswered.
If WordPress had no Woman contributors, the training team wouldn’t have created lesson plans to help anyone teach WordPress.
If WordPress had no Woman contributors, most waapuu would never have been designed.
If WordPress had no Woman contributors, WordPress would be inaccessible to many people using assistive technology.
If WordPress had no Woman contributors, WordPress wouldn’t be fully translated in over 60 languages.

There is no area of WordPress that is untouched by the contributions of Woman. In honor of International Woman’s Day tomorrow, my friend Mika is participating in “A Day Without Women”. I support her and every other Woman of WordPress that chooses to do the same.

The theme for 2017’s International Woman’s Day is “Women in the Changing World of Work: Planet 50-50 by 2030”. While Planet 50-50 ignores the gender non-binary members of the world, it’s a phrase that aims to seek equal representation, recognition, and opportunity.

For my fellow men of the WordPress community, I encourage you to make sure a woman who’s work you appreciate is known tomorrow. Without the contributions of woman, WordPress would be worse off.

“My Code is Self-Documenting” — Eric Holscher 

Self-documenting code is one of the biggest documentation myths in the software industry. This view generally conflates documentation with code comments. I’d like to make two arguments in this post:

Code comments have value

Documentation has more value than just explaining how software works

Source: “My Code is Self-Documenting” — Eric Holscher – Surfing in Kansas

Being an Ally

It’s even more important than usual for privileged allies to be good allies right now.  I’m “safe” compared to many others since it’s my beliefs that are under attack, not me as a person. Being a good ally isn’t easy; I know I get things wrong. But here is what I am trying to do in order to be a good ally online.

  1. Amplify the voices that aren’t being heard.  I’m trying to make sure that if a marginalized person says something I think is worth being heard that I share it.
  2. Be a little less worried about being a white knight and come to the defense of marginalized people that are attacked. I’m making sure I don’t talk over people. And I’m trying to be respectful.
  3. Thanking, congratulating and supporting. It’s not easy to be on the front lines and so when people are, I’m trying to make sure they know the work they do is appreciated.

In person, I’m trying to be an emotional support person for friends that need it. I’m wearing my feminist shirts to show other men that there it’s ok to be feminist.

Also, every time I get really pissed off, I donate to Planned Parenthood, the ACLU, and other organizations to make sure they can do the work the country needs them to do.

I’m sure I can do more, and I’ll figure out how.  But for now, that’s me.  What are you doing to be an ally?

Some Recent Paintings

I’ve been continuing to have fun with watercolors.  I find the process of creating something tangible to be a nice contrast with the majority of my day where I am creating digital things.

My friend Brian celebrated the second anniversary of the Post Status Club where he provides excellent news and insight for the WordPress community along with a clubhouse for to gather (in this case, slack).  To commemorate it, I made a little painting

I’ve also been spending a lot of time thinking about the concept of Love and the power it has to shine through.  It’s also a universal concept.  Love exists everywhere and in many different forms.  This painting is part of a larger series that explores that idea.

 

Commit Messages are about Intent

Commit messages are user experience for developers.  Both for other developers active right now and for developers (including ourselves) days/years/months from now. Think about the last time you were looking at a piece of code and asked yourself “Why is this here”.  This is for you, this is your experience. I shared my four rules of thumb for commit messages, this is a little more in-depth.

Caleb Thompson proposes three questions that all commit messages should answer:

  • Why is this change necessary?

  • How does it address the issue?

  • What side effects does this change have?

In general, the first and second is the easiest to answer. In many cases, a link to your bug tracker will suffice (at least in part) for the first question. Your bug tracker should already contain the *why* for every change requested. The second question  is important when the solution is complex.

Does this mean that all commit messages need to be bland? Absolutely not. WORLD WAR Z-INDEX: Restoration of sanity to revisions/slider/menu z-index values. is an excellent example of a commit message that is both fun and informative. The changeset is small ( 3 lines changed, 4 deleted), and is fairly easy for us to answer the question “What is changed?”. The why is answered with both a link to the ticket of

Erlang/OTP identifies three important purposes that commit messages serve:

Good commit messages serve at least three important purposes:

  • To speed up the reviewing process.
  • To help us write a good release note.
  • To help the future maintainers of Erlang/OTP (it could be you!), say five years into the future, to find out why a particular change was made to the code or why a specific feature was added.

The third reason to me is likely the most important.  Boone Gorges identifies blaming and annotation to be important tools in understanding the history of code and history of decisions in his talk Building a Better WordPress through Software Archaeology. Our software has a history and commit messages are the first draft of that history.

 

Further reading:

Commit Often, Perfect Later, Publish Once: Git Best Practices

Best Practices vary from environment to environment, and there is no One True Answer, but still, this represents a consensus from #git and in some cases helps you frame the discussion for the generation of your very own best practices.

On commit messages

Any software project is a collaborative project. It has at least two developers, the original developer and the original developer a few weeks or months later when the train of thought has long left the station. This later self needs to reestablish the context of a particular piece of code each time a new bug occurs or a new feature needs to be implemented.

5 Useful Tips For A Better Commit Message 

Having a story in your git log will make a huge difference in how you and others perceive your project. By taking great care in commit messages, as you do in your code, you will help to increase overall quality.

The Art of the Commit

Think of the commit log as a newsfeed for your project, in which the log message is the headline for each commit. Have you ever skimmed the headlines in a newspaper (or, for a more current example, BuzzFeed) and come away thinking you’d gotten a summary of what was happening in the world? A good headline doesn’t have to tell the whole story, but it should tell you enough to know what the story is about before you read it.

New BASH Prompt

For the last few years, I’ve been using impromptu for setting my bash prompt. However, it felt in perpetual beta status and I wanted to try out something new, so today I installed bash-git-prompt and am giving it a try.

It was super easy to get started with it following the instructions.

  • Run brew update
  • Run brew install bash-git-prompt for the last stable release or brew install --HEAD bash-git-prompt for the latest version directly from the repository
  • Now you can source the file in your ~/.bash_profile as follows:
if [ -f "$(brew --prefix)/opt/bash-git-prompt/share/gitprompt.sh" ]; then
  __GIT_PROMPT_DIR=$(brew --prefix)/opt/bash-git-prompt/share
  source "$(brew --prefix)/opt/bash-git-prompt/share/gitprompt.sh"
fi

So far, it seems like something that should do the job. If not, I’ll look for a new solution. Let me know in the comments how you setup and manage your prompt.

WordPress JSHint Adventure

NOTE: I found this draft originally written on December 19, 2013.  Not sure why I decided it should remain unpublished, but I did and then like many drafts, I forgot about it.  So here it is.


One of the features of WordPress 3.8 is something that users will never notice. In fact, it’s something that most developers will never notice as well. It was establishing greater standards with the core JavaScript and adding JSHint.

JSHint is a tool that detects errors and potential problems with JavaScript code. They range from the annoying ( trailing whitespace ), to the potential bug inducing ( code in a function after a return ), to the likely to break a browser we still support ( a trailing comma in an object ). Adding JSHint was initially discussed around the same time as the creation of http://develop.svn.wordpress.org, but it wasn’t until the start of the WordPress 3.8 that much progress was made. K. Adam White led the effort to create the initial .jshintrc (which is the configuration JSHint uses) along with the grunt configuration to make running JSHint easy.

Once the configuration was decided upon, the process of fixing up the files was relatively quick and straightforward. A list was built and maintained of all files, and then edited to note the person who signed up to fix it and the ticket number.  Overall, from publishing the post until the last file was cleaned up it took 7 days.

By going file by file, we minimized the churn and made it simple for committers to review. It also made it easy to find bitesize chunks. Overall, 13 individuals wrote patches in addition to the committers who assisted.