Hi, it is exciting to see all the developments in Discourse each day. I wonder if anyone else feels overwhelmed by the challenge of keeping up with all that is changing? If so, I wonder if the team might consider - now or in the next six months or so (?) - releasing a weekly/bi-weekly newsletter with the most important updates that have taken place to the Discourse software? This could have multiple benefits:
Make it easier for people to focus on using Discourse rather than keeping up with the Discourse project.
Have an authorized history of the development of Discourse. Good reference documents to point people to who have questions about can Discourse do xyz.
Give the Discourse team a regular opportunity to celebrate and promote the rapid pace of Discourse itself getting even more magical.
Give the Discourse team a regular opportunity to celebrate the Discourse ecosystem - plugin authors, successful launches, milestones, etc.
The release blog posts only come out for each stable release (AFAIK). That addresses points 2-4 above, but not point 1.
The install instructions and the advice on meta all say to avoid the stable branch and use tests-passed.
Therefore the blog posts can often come out months later than the changes to people’s forums. For people running communities I think this is a bit late to hear about changes.
I’ve started watching the announcements category; excellent suggestion!
At the same time, I think the announcements category has a very narrow focus. A biweekly feature including a 1-2 sentence update on each of the plugins, on new features being considered, shout outs to top contributors, and other significant happenings in the broader Discourse universe would be helpful. The expert perspective on “here’s the significant updates from across the community” would give me peace of mind that I don’t need to follow everything to stay up to date. Discourse’s openness and transparency is awesome and inspiring, but it is a lot of volume to keep up with vs focusing on my particular community.
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.
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.
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…
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.
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.
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?
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.
Ugh, horrible marketing-speak (makes the sign of the cross). You can at least view https://twitter.com/discourse to see somewhat interesting user-facing features being announced.
Not sure why that wasn’t mentioned earlier, but it should have been.
Yeah, the language used doesn’t really match Discourse’s tone, I agree.
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…
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?
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:
Discourse is improving rapidly (from a baseline of awesome).
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.
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:
Discourse can win the game on technical merits. But it can also win the game on customer service. Double plus good.
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.”
This was announced some time ago on Twitter at https://twitter.com/discourse so I suggest following that account. I am not sure why anyone from our team did not mention that previously.
) but it is an audience nonetheless.
