New structure and posting conventions for #feature category

site feedback
1

We’re making some changes to the #feature category.

  1. #spec and #rfc are now just tags (and I added rfc to all of them because I’m hoping we can phase out spec entirely)
  2. We have a new category called #feature:announcements

A new convention for feature announcements

When a new feature has been merged into the beta branch (i.e. it is already or will soon be deployed to all of our customers), we will now typically create a new topic for it in #feature:announcements.

This means we’ll (try to) change our usual convention of:

  1. Reply to existing feature discussion with a final feature announcement
  2. Close the topic

With:

  1. Close the feature discussion.
  2. Reply with a new topic that explains & formally announces the feature (usually borrowing copy from the former feature discussion).

We’re trying to achieve a couple different things with this new category:

  • Establishing a clear delineation between pending (speccing, planned, needs feedback etc.) features and completed features.

  • A “new features feed” in for site owners to follow via Discourse, RSS or the API.

  • An actual RSS/API-friendly feed of features would also pave the way for easy integrations elsewhere, e.g. a feed of “New Features” in our upcoming new Dashboard.

  • Provides us with clean-written features that can more easily be tweeted out without confusing newcomers by dropping them into a long feature discussion. There’s even an opportunity to automate this.

What is the difference between Releases and Feature Announcements?

Whereas #releases contains exhaustive changelogs per release, #feature:announcements keeps you up-to-date with the latest changes that have just gone live. This more accurately reflects the “incremental updates” release schedule which applies to all our customers and most self-hosted users.

14 Likes