Weekly Discourse Summary?

(Jeff Atwood) #11

Why do you need to keep up with it? Can you cite some specific examples of where this affected you, and why, with details? I feel like you are opting in to a treadmill that you perhaps don’t need to be on?

For example I use Slack daily but I don’t follow its development and I can’t think of any reason I would need to?


I’m not sure the situation is the same though. You use Slack but you’re not responsible for maintaining a Slack instance for your users so you don’t have to answer questions that they have about features.

(Jeff Atwood) #17

Sort of, we use it at the org level, so I am technically responsible for it working for all the employees of CDCK, Inc.

It is a tighter audience (21 people! :tada:) but it is an audience nonetheless.


Hmmmm. I don’t see it as the same.

If something major changes at UXMastery, as the CM and admin I expect my members to come to me with questions or voice concerns and I see it as my responsibility to have answers. In some cases I’d like to be able to pre-empt change with an announcement.

If Slack changes in our workplace I don’t see it as your job to keep us in the loop.

That said, I don’t have a simple answer to this but I’d like to see a change so I’ll do some DD.

(Jeff Atwood) #19

In the case of Slack, wouldn’t you just refer them to Slack’s documentation?

For example, you brought up discobot, the new education / training bot tool. Wouldn’t you simply refer a user – or a mod, or really anyone – who asked “what is discobot” to the blog post we made about it?

The difficulty there is the (long, in this specific case, because it was very hard to build) transitional period where we were building the feature and gathering feedback on it. It is premature to document things formally (or even announce them) when they are in progress, and may change…

(Barry van Oudtshoorn) #20

It’s probably also worth noting that Slack is fairly static compared to Discourse: Discourse continues to evolve and improve at a rapid rate, with big changes like improved markdown, a new composing/editing workflow, a different way of working with images, a new emoji picker, etc., while Slack expends vast engineering resources on changing the way they handle @ completion. :wink:


Sure, that’s doable, but now the onus is on me to check the blog, Twitter and the #releases category regularly. While that’s not insurmountable and could be considered part of the job, most CMs are not in that habit and most platforms don’t require it.

(Jeff Atwood) #22

It’s usually not required because it doesn’t matter. I could list a dozen new Slack features that have had absolutely zero relevance to me, or the team.

The desire to vet the new feature list (outside of formal version releases) is something that a handful of people might be interested in?

(Barry van Oudtshoorn) #23

Something that we’ve found to be really helpful in our own software is a “release alert”, used in conjunction with blog posts, newsletters, direct mail, and community announcements. Probably the most common example is Office365: when something changes, you get a small summary of those changes; something like this:


We can choose the audience for each “alert” that we show, so that the right people are aware of the changes that have happened.

Perhaps something similar would work for Discourse – at least for really significant changes, like the new composer.

(Jeff Atwood) #24

Ugh, horrible marketing-speak (makes the sign of the cross). You can at least view Discourse (@discourse) | Twitter to see somewhat interesting user-facing features being announced.

Not sure why that wasn’t mentioned earlier, but it should have been.

(Barry van Oudtshoorn) #25

Yeah, the language used doesn’t really match Discourse’s tone, I agree. :slight_smile:

I think that this is symptomatic of why this topic exists at all. There are, perhaps, too many channels to get information about Discourse changes – but none are the One True Source. Perhaps, rather than a weekly summary as originally proposed, one of the existing channels should be elevated into that One True Source? My recommendation would be the blog…

(Jeff Atwood) #26

Sure, but if we do a blog entry for every weekly beta release, instead of every official version (1.5, 1.6, 1.7, 1.8 etc) we have multiplied the necessary work by 10-15×. And remember, all the highlights would be in the blog post for the formal release.

Maybe the #feature:announcements category could have a much briefer summary of changes for each beta release?

(Barry van Oudtshoorn) #27

That’d definitely be a big improvement!

(Carson) #28

Hi, I appreciate the discussion! Even if this doesn’t happen, I’m so grateful that the idea is taken seriously.

@codinghorror, here’s an example: if I didn’t follow meta, I might not know that the composer was about to change! That’s a big deal. For peace of mind, knowing that’s about to hit my community is important. I might want to announce it or be prepared to field questions - even simple ones like, “Why is this different?” Vs. getting a question from someone and saying, “oh, I hadn’t logged on yet, I didn’t realize they had changed that feature.”

Edit: Another nice feature - the Christmas hats theme! So much fun. That’s a “small” new feature, not official, but it is interesting and unique. Pushing that out to everyone, at least as a one sentence line of “something new in Discourse”, adds value by making it easier to realize what’s new and valuable about the product.

The “problem” is:

  1. Discourse is improving rapidly (from a baseline of awesome).
  2. Dozens of changes are considered each week in meta. Some of them jump from “we’ll think about it” to “pr-welcome” to “here you go” to “merged into core” quite fast. Or they are bugs that are fixed that change functionality or solve problems I (or a community member) might have had.
  3. The Discourse updates, as far as I can tell, are about Discourse’s core - but not the plugins. The plugins make Discourse even more awesome, and seem to be an integral part of the open source nature of the project. Right now they are kind of left to fend on their own? As a non-technical CM, that pushes those off the table for me, at least at this stage. If Discourse told me, “this plugin is now official” or “people are raving about this plugin, check it out” that would help.

In terms of the solution side:

  1. Discourse can win the game on technical merits. But it can also win the game on customer service. Double plus good.
  2. A single source of truth aligns everyone.

If you help us look awesome to our colleagues and our communities when talking about the upgrades to the product, we’ll be even happier than we are now. I’m saying, every week, I’d love to be more excited about what you’re doing.

It is also an opportunity to clarify what feedback is most valuable to the team. E.g., maybe poll customers on, “hey, in meta we’ve had requests for five possible development projects, what’s most important to you?” Or, “we’re actively testing these two features, please let us know if you want to weigh in on them and how that might affect your community.”

(Jeff Atwood) #29

This was announced some time ago on Twitter at Discourse (@discourse) | Twitter so I suggest following that account. I am not sure why anyone from our team did not mention that previously.

(Erlend Sogge Heggen) #34

Thanks for the feedback @outofthebox and @barryvan. We are continuing this discussion internally and will be trying something out based on the suggestions given here.

We’ll resume this discussion in public once this new approach is being put into practice.

(Erlend Sogge Heggen) closed #35

(Joshua Rosenfeld) opened #36

(Joshua Rosenfeld) #37

OK, thanks for bearing with us while we fleshed this idea out. Here’s what we’ve come up with:

From the #feature:announcements post:

While we have always posted detailed release notes for major version along with a blog post highlighting major features, we don’t generally talk about our 10+ beta releases leading up to the major release. After hearing feedback from members of our community, we’ve decided to try something new moving forward. We’re going to share release notes for each beta. They’ll feature the beta’s “Greatest Hits” - explanations of new changes that we think everyone should know - as well as a list of smaller changes that don’t need quite so much detail.

We didn’t feel like a weekly update made sense. Development is not “constant”, we don’t use weeks as a deadline/timeframe, so weekly updates do not reflect our development cycle. We release a new beta when we have something new to share that is stable for sites to update. The last thing we want to do is share an update about a new in-progress feature and then have everyone update only to find it’s not fully ready yet.

We plan to try these release notes out for a few betas and see how they go. Let us know what you think about them here.

I actually posted the release notes a few hours ago, but messed up security permissions on the category so only the team could see it :sweat_smile:

Also, we’ve decided to restrict replying in the #feature:announcements category, just like we do in the #releases category. We don’t want to split discussion about a feature into multiple places, so feature discussion will continue in #feature, #feature:announcements will be reserved solely for the announcement itself. Bugs for new features should be reported in a new #bug topic, unless we have a “help us test xyz” topic linked.

Which branch of Discourse is used internally?
(Carson) #38

This makes sense. I think the amount of detail in the first announcement makes the point. The progress is rapid and moving ahead on many fronts. Reading through it a few times really helped me understand what’s happened. Thank you!