One of the biggest changes we made was an overhaul of the Broadcasting screen. Here is the “before” version:

This worked OK, but you can see a few problems:

• You can’t send different messages to different accounts on the same service. This was something I wanted to be able to do, to have different voicing on @alexkingorg and @crowdfavorite.
• Facebook pages aren’t visible by default.
• The character counter limit indicator is too far away from the textarea it is reflecting.

So we worked on some different approaches. These are pretty close to what we shipped in version 2.5:

And here is the version that shipped:

We also made some significant UI changes to the way accounts are managed on the admin side. Here is the “before” version.

Again, functional but can be improved. In particular I wanted to consolidate this into a single list rather than having one place to add/remove accounts and a separate place to indicate the default accounts. Also, you can see the problem (again) of pages not being shown by default.

This concept allowed the two lists to be combined into one:

And what we shipped was pretty darn close to that:

In addition to making the admin screens more compact, this design also makes it easier to support more services in the future (Google+, etc.).

So there you have it, a little “behind the scenes” fun. I definitely recommend incorporating sketching and wireframing into your design process, it’s been a huge help for us as we brainstorm, discuss ideas, etc.

Here are the high level bullet points:

• easily connect your Twitter and Facebook accounts (no need to create apps through their developer sites and copy keys around – this feature enabled directly by MailChimp)
• allow any other authors on your site to broadcast their own accounts, as well as to any global accounts for the site
• broadcast your posts to Twitter and Facebook (with customized messages for each account)
• pull social reactions on Twitter and Facebook back in to your site as comments (this could be liking or retweeting your broadcast, replying with a comment, or just tweeting a link to your post)
• ability to reply to these social reactions from your WordPress site and send them back to the appropriate social network (keep the conversation going)
• your site visitors can authenticate with their Twitter or Facebook accounts when commenting (and they can optionally post their comment back to their social networks)

Pretty good feature list, right? Social also has a couple of great collateral features. When used in conjunction with the “users must be logged in to comment” feature of WordPress, you can choose to require your commentors to attach a more meaningful (and verified) identity with their comments. Removing anonymous noise from the mix always raises the level of debate.

Social also allows your site to be the place for your content. You can bring in conversations from both Facebook and Twitter back to your site, while still participating in the conversations on those social networks. Engage with people where they want to engage, but do so while providing a richer cross-network experience on your own site.

That’s Social in a nutshell. Which brings us to the “what’s new in this version” list. I did most of the coding on this release so I’m hardly unbiased, but I’m pretty darn pleased with the way this version has shaped up. I’ve been using development builds on this site for a bit now, and I really like the way the new features have removed that last little bit of friction from some of my more common interactions.

Before we launch into what’s new, I’d like to take a moment to point out that Social is built entirely in the open on GitHub. Developers, please send us awesome pull requests.

Facebook Improvements

I think some of the best changes in this version are in the improvements to interactions with Facebook. By default, when a post is broadcast it is sent as a link rather than a status post; regardless of if it has a featured image or not. The obvious exception here is for posts that have a status post format – those are still sent as status posts. To try to make this interaction clear, we show a nice preview of how the post will look on Facebook on the broadcast screen.

When comments are broadcast to Facebook, we try to do the Right Thing with it. There are two options:

1. The comment is replying to an existing comment thread and we should post it back to the same thread in Facebook. If this is the case, we try to do so. If for some reason (permissions, etc.) we aren’t able to do so, then we fall back on option 2…
2. Post the comment with a link to the post to the commentor’s timeline. It makes more sense. Their comment is on the link, and the link is posted right along with it. This should make the posts going back to Facebook more meaningful.

We also take the step of auto-selecting the “Post to Facebook” checkbox under the following conditions:

• The (admin/author) user has a Facebook profile attached to their account.
• The comment they have clicked “reply” was imported from (or was broadcast to) Facebook.

Social does this all for you – just hit reply, type your message and send. This feature is important to keep the conversation running easily on both Facebook and your WordPress site.

Twitter Improvements

Twitter integration got some nice improvements in this version as well. You were previously able to import tweets as comment directly by URL, but now you can do this from the front-end as well. Use the menu we add in the admin bar under the Comments item to bring in tweets directly (and look for social comments). This is really useful for bringing in replies to replies or other tweets that are part of the conversation, but not something that Social will pick up by default. Note that you have to be on a single post (permalink) view for this to be available.

One of the use cases that I think makes Social really interesting is the way it allows your WordPress site to interact with real-time happenings on Twitter. Did someone tweet something that prompted you to write a blog post? You can send your broadcast tweet as a reply to that user.

Tip: Make sure to include their @username in the tweet so that they see it as you expect.

We also improved the Twitter comment detection to auto-select the account that a tweet was directed to when replying to an imported comment. Huh? Basically, if @someoneelse sends a tweet to @yourusername and Social brings that in as a comment, Social will also select your @yourusername and check the “post to Twitter” box when you hit the Reply link for that comment. It also inserts @someoneelse into the comment box so that you can start writing your reply.

The last significant change we made is to widen the net a little and catch specific types of Twitter replies, then import them as comments. The scenario is basically this:

1. You broadcast a post.
2. Someone replies to your post, this is imported as a comment on your site.
3. You reply to that comment on your site, and broadcast it back to Twitter.
4. The other person (or multiple people) reply to that comment.

Previously we would have missed automatically importing the replies in step 4 above. Now we catch them.

We walk a fine line with the amount of content we try to find and import. In particular we want to make sure we don’t set up rules that allow Social to use up all of your API requests checking for comments on your broadcasts. However, we do want to bring in as many relevant reactions as we can. We were able to make this change without requiring an additional API hit. We are able to look for additional data in the API requests we were already making.

General Improvements

You can now send customized broadcasts to each account in a single action – each account has its own form that you can edit. By default, the first broadcast message for each service (Facebook, Twitter) is editable while any others are in “copycat” mode. They will all be updated along with the edits to the first message unless you click the Edit link for the ones you want to customize. We think this is a good compromise between convenience and control, and hope you like how it works.

The account management forms have been streamlined and cleaned up, on both the main Social settings screen and the user profile screen. For example, Facebook pages are always displayed so they can be selected, etc. We also consolidated the selection of “default” accounts into the main accounts list. We hope this makes these pages easier to understand and use.

Some of you have post broadcasts that get a ton of Likes and Retweets. These are cool to see in the (condensed view in the) comments list, but not as meaningful in the comments RSS/Atom feeds that WordPress generates. We’ve added some code to suppress these types of “meta” comments in the feeds.

When you have lots of comments, they come with a lot of in-page image requests. This can cause your site to load more slowly than you’d like, so we implemented support for the Lazy Load plugin. Install and enable this plugin, and the avatars for your Social comments only load when scrolled into view.

Social now functions as a platform for other social WordPress plugins. You can choose to disable any features that you don’t want on your site and just use the connections to social networks. Expect a new release of Twitter Tools, built on Social, very soon.

Of course we also fixed all of the bugs we were able to reproduce. This includes making Facebook comment importing more consistent, along with a number of other fixes and improvements.

A quick word about Google+ integration (by far the most requested feature – tracked here). It’s something we want to do and plan to do, but until Google+ has a write API we can’t attain feature parity with our Facebook and Twitter integrations. My guess? We’ll see a Google+ API featured next month at Google I/O.

Want to build cool WordPress integrations like this? We’re hiring.

Social is a plugin that allows you to maintain a centralized conversation on your site, while also participating in conversations on Facebook and Twitter.

Congratulations to Brad on today’s launch of WP App Store. I’m very pleased to see this come to life. It’s an idea we toyed around with several years ago, but decided not to pull the trigger on – I hope it’s a huge success.

We’ve put our FavePersonal and FaveBusiness themes along with our RAMP plugin into the app store. If you’d like to check it out, download the plugin and start browsing. There is a great group of companies represented already and I’m sure we’ll see more additions as the project grows.

Fellow Colorado web geeks, I made you a t-shirt.

The code that comprises the white stripe is a full, working HTML page with canvas code that draws the Colorado flag. Yes, it’s very meta.

Want one? We’re taking orders for the rest of the month, then we’ll place an order to get them all printed up. These are priced just above cost ($15, plus $5 if you need it shipped) – we’re not trying to make money on them. I initially ordered a batch for my team, but thought others might like it as well. If early response is any indication, I hope to see a few of these around town this summer.

It’s baseball season again, and in downtown Denver that means traffic and bad cell phone connections. We can’t do much about the latter, but be sure to use GameTonight for warning about potential traffic concerns.

GameTonight is a single-serving site that answers “is there a game tonight?” and tracks the major sports teams in 1516 metro areas:

• Atlanta
• Bay Area
• Boston
• Chicago
• Cincinnati
• Dallas
• Denver
• Los Angeles
• Minneapolis
• Oakland
• Philadelphia
• Phoenix
• San Francisco
• San Jose
• Seattle
• Washington DC

If you live in one of these areas, check it out.

As the version number indicates, this release is primarily to deliver a few bug fixes. Here is a quick overview of the significant changes:

• improved compatibility with changes introduced in WordPress 3.3
• properly handle entirely numeric category and tags names
• improved support for hierarchical taxonomies
• misc. cleanup of PHP notices (when the WordPress DEBUG setting is enabled)
• minimum required WordPress version is now 3.3

For a little more detail about just what this product is all about, check out my original post announcing RAMP.

While I’m mainly using the “out of the box” features of FavePersonal, I have applied a number of customizations to this site. A child theme is a great way to customize a theme and still be able to upgrade without losing your changes. For the customizations I’ll be sharing about FavePersonal, we need a very simple child theme – just a style.css file and a functions.php file.¹

One of the things I’m using my child theme for is to streamline the HTML I deliver for my pages. I haven’t changed the colors for this site in nearly 10 years, so it’s safe to say I’m not planning to tinker with them much going forward. Since I don’t need the flexibility of being able to swap out the colors, I moved the CSS rules for the colors out of the HTML and into my child theme.

The first thing you’ll want to do is download the style.css file from your Theme Settings page. (Don’t have FavePersonal yet? Check out the online demo.) This gives us our colors, so now we just need to remove the CSS from the HTML.

In the functions.php file in your child theme, you’ll want to add the following code to remove the output of the CSS rules from being added to your HTML.

View the code on Gist.

Now you can activate your child theme and your site should look just the same, but load a touch faster (and give you a nice place to make future customizations).

Another little change I made in my child theme is to add actual underlines (gasp) to links. I don’t think I’ve met a designer in the last five years who still uses underlines in their designs, but I’m old school , I like underlines on my links. I think it helps them stand out better. However I do agree that underlines clutter up areas where things are expected to be clickable (navigation menus, lists, etc.), so I’m just adding the underlines to links in the content area of the site.

Want to underline the links in your FavePersonal site as well? Grab this CSS snippet and paste it into the style.css for your child theme.

View the code on Gist.

And there you go – a few simple customizations for your FavePersonal child theme.

We’ve made it easy to experiment with different colors and find a set that makes your site feel like it’s your own. No need to fiddle through dozens of color pickers, you can choose from full color palettes, preview them, and instantly apply them to your site.

You can browse through existing color combinations to find some initial inspiration. Use the tabs at the top (and the pagination links at the bottom) to navigate through the most popular, highest rated and newest palettes, or just look at a random set. Not seeing anything that grabs you? Try a search. For example, “desert rose” will bring back just what you might expect.

Whenever you see a palette you think looks interesting, just click the Preview button to see how it might look applied to FavePersonal. If you like what you see, you can Select it to move that palette to the selected colors area at the top of the screen. From there, just hit Save Changes, and the color palette will be applied to your site.

But maybe you’ve found a color palette that is almost right, but you want to tweak it a little bit. No problem. Once the palette is selected (shown at the top of the colors screen) you can customize it however you like.

The first thing you may want to experiment with is how the colors are applied to different areas of the FavePersonal theme. FavePersonal takes the color from each of the five positions and puts it into a specific areas in the site. This is done in a way that should provide an appropriate amount of contrast between different elements on the site (but you’ll see that some themes work better than others). By clicking and dragging on the colors to re-order them, you can have them applied to different areas of your site. Click the Preview button to see how things look after moving them around.

When you have the colors applied to the areas of the site in a way that you like, you might want to apply a few tweaks (or maybe you have an explicit color scheme you want to enter). No problem. Click on each of the colors to reveal a full color picker where you can make minor adjustments (I want a darker or lighter share of blue here) or just choose another color altogether. Then click Preview to get an idea how it might look, and Save Changes to apply it to your site.

Have you come up with an original color combination that you love? Add it to Adobe Kuler and you’ll be able to re-apply it to your site easily by using the search feature (you can search for your username or the name of your palette).

I think we’ve succeeded in providing a good way for folks to choose good looking color schemes without “needing to be a designer”, while also providing the fine grain control that other folks (like me) want for their site.

While we were creating FavePersonal it was fun to see our team experimenting with the Colors feature and really getting sucked in to it – it’s a great way to lose spend a few hours.

Don’t take my word for it though, go try it out for yourself with our online demo (click the Theme Admin button to log in).

I think it was two or three years ago that I first had the idea for using color palettes with a theme in this way. I was pretty sure it would work, but hadn’t really seen it done in the manner I was imagining. I started doing some prototyping and ran into a snag.

In order to apply a color palette to a design with (generally) positive results, you need to be able to reasonably predict the colors that will have contrast between them. When looking at color palettes from a number of sources, I found that they came through without any particular ordering of the colors.

Step one became coming up with an algorithm that would work to get the colors sorted in a reasonable fashion. This is not a trivial problem, but interestingly the more complex we attempted to make the solution, the worse things got. Eventually, after running a few different approaches against a test set of color palettes, the most simple and naive approach seemed to yield the best results.

Basically I took the numeric value of the first digit of the RGB values from the hex color, add them together to get a total numeric value for each color, then sort the colors by that value.

View the code on Gist.

I think this could be refined a little further, perhaps adding a slight bias towards blue or green over red in order to better handle cases where you might prefer certain colors that are close in “brightness” to be considered “darker” than others.¹ For FavePersonal I decided that it was better to handle this by allowing people to drag and drop to re-arrange the colors in the palette instead.

We’ve released the colors feature we created for FavePersonal on Github. It’s a designer/developer tool as it’s not something that works as a stand-alone plugin, but it works quite nicely when integrated as a feature of a theme.

The features for FavePersonal were driven by my goals for version three of this site. I wanted the site to be personal, be a great showcase for my content and to integrate with my other social interactions online.

Personal

One of the features I know people will enjoy playing with is the Colors feature. Instead of fiddling with lots of different color pickers, you can select from thousands of existing color palettes (via Adobe Kuler integration) and instantly preview and apply the scheme to your site.

The header options and bio widget features were created to help tell the “this is who I am, and what this site is” story. Most visitors arrive on an internal site page via search engine or direct link. These features serve to provide some context about both you, and your site.

All Kinds of Post Content

With FavePersonal we have integrated our post formats admin UI functionality to make it easy to post photos, galleries, videos, etc. Each of these types of content is elegantly managed and delivered, from the back-end admin interface all the way through to customized layouts appropriate for each type of content, and formatted elegantly for mobile devices (even extending to your RSS feeds).

See some examples on this site:

• Status posts
• Link posts
• Photo posts
• Gallery posts (be sure to check out a gallery post)
• Video posts

Social

If my site is going to represent me on the web, it’s not telling a complete story if it ignores my participation on other social networks. FavePersonal tightly integrates with (and includes) the Social plugin to create a two way integration between your website, Twitter and Facebook. You can post status updates on your site then pass them on to your Twitter and Facebook accounts. Social will bring retweets, likes and reactions from those sites back to your site as comments.

Additionally, your visitors can log in with their social profiles when they comment directly on your site.

Mobile-Friendly

FavePersonal was designed from the ground up to be responsive. Not only does it look great on your computer, but also on your phone and tablet device.

Are you on a mobile browser now? Check out the online demo and see how it works. Be sure to rotate and see how it adapts to portait and landscape orientations.

Of course it is optimized for fast page loads and also features clean HTML5 markup that is both human and machine (SEO) friendly.

This is just a very brief sampling of what we’ve put into FavePersonal. We’ve been working on this theme for over a year.¹ We’ve given every feature a ton of thought, debate, tweaking, building, throwing away, re-building and testing to get things the way we want them. I’ve been told I can be a bit particular , which is a kind way of saying I’m a pain in the arse and we’ll re-design things as many times as it takes to get it right. My team has been very patient with me, coming up with great ideas and solutions and building them in elegant ways. We’ve built deep features on solid foundations that won’t break or surprise you as you lean on them and come to rely on them.

I’m going to be following up with a series of posts that go into more detail about the various features of FavePersonal, discussing some of the design decisions we made, and sharing customizations I’ve put into my own child theme. I’ll also point to some of the code we’ve released on our GitHub account for anyone who would be interested. I’ve got a pretty good sized list.

When I started using FavePersonal in August of last year (2011) it became the third version of this site since it launched in 2002 (check out original version from 2002 and the previous version from 2006). With each iteration I always received a number of “is your theme available?” inquiries. In the past, my themes have always been built with too many content assumptions, etc. for me to effectively share it, but I made sure we didn’t do that with FavePersonal.

Check out the FavePersonal page on the Crowd Favorite website to see our feature videos, try out online demo and purchase (our new store² supports PayPal as well as credit cards).

I hope you like it as much as I do!

The themes are being renamed:

• Carrington Blog is becoming FaveBlog
• Carrington Text is becoming FaveText
• Carrington Mobile is becoming, you guessed it, FaveMobile

We caused a bunch of confusion around the name “Carrington” when we attached it to everything. I’m hoping that removing it from the themes and having the “Carrington” name reserved for our underlying theme features (Carrington Core and Carrington Build) will help make it more clear that Carrington refers to our collection of developer and designer tools that make it easier to create great websites with WordPress. We’ve also initiated an internal project to create better designer/developer documentation for Carrington Core.

Updating the themes to the latest and greatest WordPress features and best practices is on the list for our intern projects and should be getting some attention in the immediate future. I’m optimistic we’ll have updated versions of these themes to release soon. I’m proud of our dedication to releasing code to the community, but once you hit a certain volume it becomes a real challenge to keep everything up to date.

At Crowd Favorite we write modular code (for example: lots of lean, targeted WordPress plugins instead of few complex plugins) for a number of reasons:

• it enables code reuse (DRY)
• smaller bits of code are easier to maintain, update, debug, etc.
• it’s easier to test smaller sets of features/functions

To support this approach we previously made extensive use of SVN externals in our projects. Often times active development would be happening on a specific project and within one or more of the externals within the project (to support a new feature, etc.).

With SVN externals, the included externals are automatically updated to the latest version on every update (unless you –exclude-submodules). If you follow a good trunk/branches/tags model within your externals, you can get away with this without too much trouble; you primarily point the external to the latest stable tag, but switch the pointer to trunk when active development is needed.

Like I said, it’s something you can get away with. That doesn’t mean there aren’t some challenges there. Primarily you can run into multiple people updating or needing to work on an external at the same time (and SVN doesn’t well support a branch-driven development model). You might be pulling in changes on each “svn up” that you don’t want.

With Git’s submodules, you can still bring in another codebase into your project but the mechanics of it are a bit different.

The submodule will be the entire Git repo

With SVN you can make your external point to a subdirectory of a project (this is how you’d choose trunk vs tags/1.0.2, etc.), with Git the submodule will always be the entire project. This means you’ll want to keep your code repositories lean and mean – you don’t want deep URL paths or a bunch of historical design documents and other things in there that would be considered cruft when the repo is used as a library for another project.

Because of this, we’re often maintaining two Git repos for each project. One has just the code, README, CHANGELOG, etc. while the other includes design docs, mockups, etc.

Submodules require extra steps when cloning

With a standard SVN checkout, all of your externals get populated and are ready to go right away. With Git submodules, an additional step is required after a git clone. From inside the newly cloned repo (at the top level), you have to initialize and update the submodules:

git submodule update --init --recursive

This step will get all if your submodules setup, pointing to the proper refs, etc.

UPDATE: or clone with --recursive. (thanks Shawn)

Submodules require extra steps when committing

After initialization, your submodule will initially be in a “detached head” state. This means that even though the submodule is pointing to the correct ref/code revision, but it isn’t setup to update from or commit to a specific head (branch). If you’re not used to this (or are used to how SVN externals work), it’s easy to accidentally start editing code in the submodule code while you’re on a detached head. Recovering from this isn’t particularly hard (I’ll do a follow up post with details on this), it’s just another step in learning how Git wants you to work with submodules.

When I was doing active development on a project that had SVN externals, I’d often end up making changes to the externals as well as the current project. When I did this, I’d need to commit to the external separately from the parent project. Git submodules work in a somewhat similar fashion in that you need to commit the changes to the submodule first; but there are also some additional steps involved.

Like SVN externals, you need to cd into the submodule to commit any changes you’ve made. When you’ve committed your changes to the submodule and have it in the state you want for its inclusion in the parent project, you then need to cd back up to the parent project and commit the “change” of the state of the submodule. Make sense? Basically, you commit to the Git submodule separately just like you used to commit to your SVN external. The additional step is checking out a tag, branch or specific revision that you want the submodule to “stick” at; then committing that change to the parent repository.

Submodules don’t update on their own

Recapping the previous point: submodules are stuck to the revision/tag/branch they are set up on. You have to explicitly update them, then commit the “change” of having the submodule point to a different revision to the parent repository. This is useful for situations where multiple people are updating a project that is being used as a submodule by multiple parent projects. Changes to the submodule won’t automatically be pulled into a parent project that doesn’t expect it (they have to be explicitly pulled in, committed, etc.).

Once you’re out of active development, I consider it a best practice to make sure your submodules are pointed at a tag for the purposes of tagging the parent project. That way when bugs or issues are found they are logged against the proper version of the package in question. When questions about a submodule version arise (does it include feature X?), you can answer them pretty easily by checking the CHANGELOG.

Hopefully this helps you get your head around the differences between SVN externals and Git submodules. Overall I like the implementation of Git submodules better now that I understand what they are trying to do. We’ve found that this development approach compliments the core extensibility features of WordPress very nicely. In fact, many of our plugins interoperate by implementing hooks and filters in the same manner WordPress core does.

Does building modular code (WordPress or for other PHP projects) sound like something you’d like to be doing more of? We’re hiring. As previously noted here, our careers page is a little different, and we believe in a healthy work-life balance.

It’s been very interesting to me to see how some folks are re-evaluating their work/life balance in the wake of reading Isaacson’s Steve Jobs biography (most famously, this story). I’ve been making some of the same evaluations over the last few years following the birth of my daughter.

This isn’t a new thing for me. I’ve always worked hard, often with long hours – mainly because I love building things. Finding a good balance that provides for both a rewarding work life and a rewarding home life isn’t easy.¹

Enabling this balance is something that’s been important to me in the Crowd Favorite team culture. I’ve been through the 80 hour week startup environment and seen how it burns out great people. I want an environment where people work hard and build great stuff, but are able to do so while maintaining balance. I want to keep my team engaged long-term, I don’t want to burn them out and use them up in the name of meeting some unreasonable schedule.

Saying you believe in a healthy work/life balance is one thing – lots of companies say they value it; for Crowd Favorite I’ve taken a pretty big step to back it up. As of last week, Crowd Favorite has a mountain retreat in Breckenridge.

Everyone is pretty excited about this. Each team member gets exclusive use of the place for one week a year (with their family, friends, etc.). When it’s not spoken for, anyone on the team can claim a bedroom and head up. I’m hoping that it will be an opportunity for the team to hang out together outside of the office (which, in turn, leads to working together better when in the office).

Not only does this reinforce that we’re a team that believes in a healthy work/life balance, but it also encourages everyone to get out and do something active. I’ve got a great team, and I’m really pleased to be able to provide this as a reward. Hopefully it will help with recruiting as well – did I mention we’re hiring?

The basic pitch? Work on great projects with a great team in beautiful Colorado. Use the latest and greatest technology and techniques. Work with and contribute to Open Source (particularly WordPress). All in a collaborative developer-centric environment and without the 60-80 hour work week you get with the typical “startup” environment.

The main reason for the change is to be able to support a branch driven development workflow (using Git Flow). We were already using this for newer projects (including some of our Open Source WordPress plugins that we host on GitHub), and we were seeing lots of areas where this approach would be a big improvement to our SVN workflows. We think it will especially pay dividends for our ongoing retainer clients.

With our ongoing clients we are commonly engaged in building new features and functionality while also needing to be able to make smaller changes (hotfixes) that are pushed up immediately. With Git it is easy for us to maintain development of more involved functionality in feature branches and still being able to push up quick changes as needed.

We’ve been following a modular development methodology for years, so we have a large number of libraries, plugins, etc. that are shared across various projects. Converting these from SVN externals to Git submodules was a good bit of busy work, but more importantly it required everyone to get comfortable with the difference between SVN externals and Git submodules. The biggest changes are that the submodules default to a detached head and don’t auto-update to the latest code in a branch. These are generally positives, but require changes to how you think about things. More on this in a future post.

We are using GitHub to host our Open Source projects, but we choose to host our own Git server for our private repositories. We are using Gitolite for repository management, GitPHP to provide a hackable web interface and we’re planning to use Gerrit for code reviews.

One of the other challenges was setting up a repository structure that we were happy with for our WordPress sites. We settled on the following:

/index.php
/local-config.php (unversioned – has machine specific settings)
/wp-config.php (define WP_CONTENT_DIR and WP_CONTENT_URL here)
/wp/ (WordPress core as a shallow Git submodule or SVN checkout)
/wp-content/ (plugins, themes, etc.)

This works quite nicely for simple and painless WordPress core upgrades, local development environments, and scriptable deployments. With a standardized structure, we’re also able to create scripts to automate the creation and data seeding of local development environments. We’re still working on the local dev set-up script, but I’m really excited about it. It should make it much easier for any developer on our team to quickly spin up a project and be able to contribute to it.

Does this sound like fun? We’re hiring! Come help us define and implement best practices that make developers effective; and work on interesting and challenging projects.

I’ve always struggled to write up the job descriptions we are hiring for. As I was trying to describe our current openings last week, I had a bit of an epiphany. The biggest reason I struggle to write up job descriptions is that we’re looking for certain kinds of people, not someone to fit into a specific position.

Instead of posting a bunch of individual designer or developer positions, we instead have a list of designer and developer skill sets. Everyone on our team has cross-functional skills and we consider this a real strength. For some reason it has taken until now for us to make our “hiring” page reflect this (instead of sticking to the more traditional listing of available positions).

At this time we’re looking for a few developers to join our team. Head on over and take a look. If you like what you see and think you’d be a good fit.

I’m very pleased that we have reached the point where we are hiring to work on internal product initiatives and to shore up our internal systems as well as to contribute to our WordPress consulting and custom development services.

Crowd Favorite is a little unique in that you have the opportunity to work on lots of diverse projects and cutting edge technology, but you don’t have the 60-80 hour work week that demanded by your typical startup.

If you care about building great things on the web – please be in touch.