Posted on

Underscores Development

computer screen with code

Underscores is one of the best starter themes out there. I use it as a base for public themes, and very often for custom themes also. It’s that good for several reasons:

  • Build accessibility in mind.
  • Well documented and modern templates.
  • Community effort building it better.
  • It does speed up your work.

I usually generate my new theme using but did you know that there is also site called Components? In there you can get a jump start for business, portfolio, magazine, or traditional blog theme.

With all that said, I’m not perfectly happy about Underscores development.

Underscores (_s) Development Ideas

You often hear that you should fork _s. And there are many great forks out there, like wd_s and Air. But this article is not about forks.

It’s about how _s can continue being the greatest starter theme out there.

Remember that _s is Automattic product and some (or many) of the decision are not on community hands. But if you ask me it needs same kind attention than default themes like Twenty Seventeen.

Here is my short list how we can improve _s theme development.

  • After every default theme we should look what issues was inherited from _s theme and fix them. Otherwise all the issues are inherited for all new themes generated from _s.
  • Issues and pull requests should be reviewed and discussed more frequently. I don’t even know who have access the repo, and that’s one of the problems. Transparency is always good.
  • There should be several people who takes the main lead reviewing and discussing issues and PRs.
  • Main lead could rotate in month period. And main lead would check the repo every week, or every other week.
  • Checking the repo could mean active discussion, testing the PRs, closing the issues, calling for help and second opinions and so on.

But who is we, and who can be the main lead?

By we I mean the community who are opening the issues, making PRs, discussing, testing, and making Underscores better. Main leaders probably needs to work for Automattic. But that’s okay as long as there is clear road map.

I personally try to contribute to _s theme as often I see issues. Let me know if you have other ideas how we could improve _s theme development. And have a great year 2017!

5 comments Underscores Development

  1. Great post, Sami! I particularly like your first point about doing a “post-mortem” after every new default theme to trace issues back to _s.

    Regarding transparency if issue/ticket reviews, I completely agree and recently opened up a ticket asking for clarifications (which I know you know about!). If other people are interested in that issue, I’d encourage them to weigh in the issue 1069.

  2. The leads would be anyone working at Automattic with the exception of Philip who got to keep his commit access after he left Automattic.

    Personally I am also hesitant to contribute as I am not sure when the PR will be merged.

    I would like to see regular feedback instead of instead of PR’s being merged in a merging spree.

    There is also a clash between _s fulfilling Automattic needs and at the same time as the community needs.

    I would be potentially interested in creating a fork of it. If we did something like this then it we would need to define a few things:

    • Vision and goal of the project so that it does not get bloated
    • List of maintainers or people who are interested in maintaining it.
    • We would need to fork the generator too
    1. I agree all of your points.

      With all those pain points many have their own fork of _s, I have also thought about it several times. If you decide to create your own fork I’m definitely interested contributing.

Comments are closed.