_s' Audience

[philiparthurmoore]

I'm finding it harder to determine which audience to code for and merge pull requests for as _s becomes more popular. There are a few major "stakeholders" as far as _s goes right now:

• WordPress.com / Automattic / Jetpack
• WordPress.org theme developers who download the theme from underscores.me

Automattic is the granddaddy of _s and the theme team uses _s for all WordPress.com theme development, as well as recommends it to premium theme shops on WordPress.com. This is super-important. When I think about this I want to add stuff into _s that will make it much easier to develop for Jetpack and such, and I also want to adhere to the VIP and WordPress.com scanners as much as possible.

WordPress.org theme developers have taken a very strong liking to _s, which is so nice. The big consideration here is that the theme review team has requirements. When _s is in conflict with those requirements then we are faced with making it difficult for theme developers to make good stuff easily, which is one of the goals of _s. This is when I think about the theme check plugin.

Is there a case to be made for two branches of _s, a .com branch and a .org branch? Might this alleviate some of the issues that we're facing in terms of the final say on pull requests and also make it easier to start adding more things into _s that make sense, like all the Jetpack include files that .org users might not really need?

At the end of the day this is an Automattic project but so many .org devs are using _s and it's getting a bit difficult to figure out how best to handle PRs and such. I just want to blaze through these issues and pull requests so furiously but I'm really scared of upsetting either camp. I'm in the lucky position of feeling empathy for both sides right now but the unlucky position of possibly messing something up. 😄

[mattwatsoncodes]

Hi @philiparthurmoore,

How about, instead of two branches you come up with a customisation site (similar to how you can customise names and SCSS at the moment), much like Initializr does with HTML5 Boiler Plate and Bootstrap: http://www.initializr.com/

That way you could check which components you want (or have an either/or option) and the version of _s that meets your needs is delivered?

Just food for thought.

[philiparthurmoore]

This is also a very excellent point. Maybe I should shift my focus from _s to https://github.com/Automattic/underscores.me for a bit so that we can get that in place? Seems to me that having that in place would get rid of this push and pull between needs right now.

[mattwatsoncodes]

@philiparthurmoore if I can help in any way let me know, I think it could be an all round winner.

[fklein-lu]

I don't think that we should have two branches. I also don't see what things we might have in _s that would conflict with the Theme Review guidelines. AFAIK there isn't any conflict currently, nor has there been in the past. The same applies to the VIP Scanner.

In my view, there aren't any issues, as _s does not contain any code specific to WordPress.com.

As far as Jetpack is concerned, if you don't want to use that, delete the inc/jetpack.php file and you're good to go.

[karmatosed]

I would not like to see two branches. I also would not like to see anything in _s that doesn't fit the theme review guidelines, that feels just wrong. We should be encouraging people follow them and working towards creating a better standard.

If you have added anything in that conflicts, you should not add until the foundations are in place. So for example, you should go to the theme check GIthub, and themereview channel on Slack. We should work together.

I would note with caution a lot of the flurry of additions lately, we should be careful this doesn't become a bloated framework. Nobody wants that. It shouldn't be everyone's everything. That's one of the foundations, it's a starter theme not an everything.

Perhaps in the future we build on what Sass did for _s and have ability to roll in bits. But, for now I don't see an issue. I also don't see the urgency to merge all the things. We should carefully consider anything that gets added. Time isn't something we should worry about. If it's good, we'll all agree and get it in.

[karmatosed]

I will also add that whatever we do on underscores.met and roll in shouldn't 'just happen'. It should be done because there is a direct need, not just because it's trendy or could be awesome.

My fear for this is that we have something I end up removing things from, we're in danger of this being close. If I and others that use _s now have to take stuff out - we've just shot ourselves in the foot. If we overcomplicate because we think it's cool as developers and it looses it's simple, minimal core - we're doing very wrong.

[philiparthurmoore]

If you have added anything in that conflicts, you should not add until the foundations are in place. So for example, you should go to the theme check GIthub, and themereview channel on Slack. We should work together.

Sounds like that'd be a pretty good addition to the guidelines.

I would note with caution a lot of the flurry of additions lately, we should be careful this doesn't become a bloated framework. Nobody wants that. It shouldn't be everyone's everything. That's one of the foundations, it's a starter theme not an everything.

Which additions do you consider a flurry? There aren't really many here: https://github.com/Automattic/_s/commits/master. This is a very slow project (which is totally fine!); I don't get the impression of there being a flurry of anything, really.

[karmatosed]

A flurry directly refers to the recent activity and specifically the example of something having to be reverted today.

[philiparthurmoore]

If you were me would you focus on _s or underscores.me repo given the time I'm donating to the project? Just wondering where best to put my time while avoiding making problems.

[philiparthurmoore]

I should depersonalize "If you were me" and ask "If you were a potential contributor to _s". 😄

I do very much love _s and underscores.me but if you feel like things are okay as-is with regard to the pace of things and contributions and such I can certainly focus my efforts elsewhere. All good; I just get a bit antsy when I see open issues and PRs, which is a good problem to have.

[karmatosed]

My answer is the same as any contributor:

1 If there is something you really want in that is a larger project like Sass and could be seen as an option on underscores.me. Fork it. Create a version with it in like happened with Sass.
2. If there is something you want to improve or add, then create an issue. Maybe if right do a fork (usually works for something bigger) or PR.
3. If there is a bug, then do an issue and PR if you can fix it.

We should never be afraid of forking and experimenting in them. We don't see that enough.

We also shouldn't be afraid of saying no and taking time.

[philiparthurmoore]

You've inspired me to fork the project. 🎉

Let's close this issue. I think I'm going to focus on a fork that gets things a bit closer to what I'm after while allowing _s and underscores.me to flourish as usual without too much flurryness.

[karmatosed]

Yay! I look forward to maybe being able to bring some of that fork in once it's a proof of concept. We should always keep an eye towards bringing things in.

I love the idea of forks being a way to experiment free of consensus votes, free of having to maintain a solid base. You can go wild in them. Then, if it's right, they can be brought into the project and forward that itself. Pretty cool!

[obenland]

The direction of _s has been an underlying issue for a while now, and I think it is important to have this conversation.

As @philiparthurmoore pointed out in the ticket description, _s has become huge over the last two years. For the last three weeks we've been around or over 5K downloads, that's more than any core bundled theme in the theme repository!! I hope we're all past thinking of _s as a project that focuses 100% on Automattic's and WordPress.com's needs. The direction it has been taking over the last year strongly suggests otherwise.

The project has been hitting its limitations in terms of what to add and what not to add, and now it's getting painful. @ianstewart first posted about an extended _s over a year and a half ago in an Automattic-internal post, something we took a small step towards with the addition of the Sass checkbox on underscores.me. This is where not only I, but many contributors, see us headed.

Unfortunately, _s doesn't get a lot of attention internally at Automattic at the moment. I was hoping we could get a group of people together during Automattic's Grand Meetup to update underscores.me with a Bootstrap-like interface, but that obviously didn't happen. We all have the best intentions for the project, but there is simply not enough time for us to devote to taking it to the next level. At least not right now.
But that interface is what we should focus on as it'll allow us to grow _s far beyond it is now.

It's important to understand the power of underscores.me, and that what developers actually end up downloading doesn't necessarily look anything like the _s repo. Heck, look at all the files we're excluding from downloads already!

The fact that @karmatosed is concerned about _s becoming too clunky is a great indicator that a change in that direction is overdue. But for us to say "Don't improve us, fork us" to deal with that, is probably the worst thing we can do. We shouldn't be in a situation where we can't cope with enhancements and send contributors away.

@mwtsn and @philiparthurmoore, if you'd be willing to work on the underscores.me interface, please do! That would be amazing! How does starting with a design concept sound?

[obenland]

@fklein-lu:

I also don't see what things we might have in _s that would conflict with the Theme Review guidelines. AFAIK there isn't any conflict currently, nor has there been in the past.

There is one thing, #460.

In my view, there aren't any issues, as _s does not contain any code specific to WordPress.com.

What about /inc/wpcom.php?

As far as Jetpack is concerned, if you don't want to use that, delete the inc/jetpack.php file and you're good to go.

That could be another "module" in a Bootstrap-like interface.

[obenland]

@karmatosed

I would note with caution a lot of the flurry of additions lately, we should be careful this doesn't become a bloated framework. Nobody wants that. It shouldn't be everyone's everything. That's one of the foundations, it's a starter theme not an everything.

No, that's exactly what it should be. A starter theme for everyone, that can get customized to your liking. With underscores.me, we have the opportunity to look past the size of the _s repo, and look at what developers actually end up downloading. We should leverage that.

I think thinking in terms of underscores.me vs. the _s repo is key.

[karmatosed]

My comments about 'everyone's everything' really come down to being able to pick things. I'm totally down for this concept and love the idea - always have. What I am not so keen on is charging in without it being planned out. For example the UI, which you point out lets do a design mockup - totally the right approach. Having a way to pick and then not get the extra makes absolute sense.

I will clarify my use of the term fork. I am encouraging experimentation and drawing a line between what happened with Sass there. It worked. I do not see that we have to stifle development and neither am I saying 'create a fork' in a dismissive way. It excites me that people will experiment and then bring back into the project.

Now, whether we enable a way to keep the pace and also the experimentation but also maintain a lean core - maybe that's the approach we can take with underscores.me.

As a clarification I am absolutely for the pick and mix approach, always have been. I also am for inventive _s. I am not for _s having everything in on download. This is where the choice comes. Otherwise, as I said I would have to remove stuff along with others - not the way we should go as far as I'm concerned. Going the way of opting in for things is better than opt out.

[ianstewart]

first posted about an extended _s over a year and a half ago in an Automattic-internal post, something we took a small step towards with the addition of the Sass checkbox on underscores.me. This is where not only I, but many contributors, see us headed.

The vision here is being able to visit underscores.me and, in a few seconds or clicks, download everything from an even more stripped down _s to a version that had your preferred basic layout applied, with your preferred basic font stacks, and preferred basic features.

The latter being something a theme author could quickly and safely use to bring their vision to life. Or a small web shop could use to quickly and safely build a theme for their client. The former being for those of us that want even less in a starter theme. Less is cool. More is cool.

Sort of like a theme creator thingamajig? But more like the kind I'd want myself. Something super-clean. If it worked you could have a spectrum of starter themes. An even easier to fork stripped down _s, or with Sass in it if that's your flow, or something that was more of a "starter" for people who are comfortable with more CSS and want something closer to a "finished" theme that they can work with.

As @obenland notes above, we just haven't had a lot of time to work on it.

[karmatosed]

As you can see by the link, I started an issue on underscores.me repo to try and start the design conversation. It's just a sketch but hopefully a starting point.

[mor10]

_s has the potential of being the de-facto starting point if you want to build themes with WordPress and I think that's the goal that should be targeted. What we are lacking in the community is consistency, both in plugins and in themes. _s has already gone a long way in making the baseline structure of themes more consistent, and if the goal was explicitly stated that _s is meant to be the best-practice baseline for theme development then WordPress themes would be built in a more consistent way going forward.

When you go to WordPress events and listen to where people start off it is clear that much of the fracture of the community stems from vastly different starting points and vastly different understandings of how to do things right. What we need is a "gold standard" for how to do the core things the proper way. _s should be that gold standard.