[latexr]

This is why you don’t announce future changes until they’re essentially ready to go out the door. Apple used to understand this better than most. Until you build the feature, you’ll have people asking you constantly when it’ll be done. After you build it, you’ll have people complaining that it doesn’t work exactly like they imagined it in their head. If you end up not building it and say so, you’ll get attacked for it, even by people who never knew about the plans before the cancellation.

Keep quiet about internal plans only you can affect. Let features requests come to you, monitor interest in those, and reply if they’re interesting or not feasible, so you can discuss and figure out what would work best for your users. Engage but don’t commit unless you’re certain something will happen.

I’m surprised the conversation hasn’t devolved to a bigger mess yet (maybe it’s being well moderated). It’s a shame they’re having to preemptively lock issues, but I completely get it. It’s exhausting having to deal with abuse on public forums when you’re on the receiving end and always have to keep your conposure.

[abofh]

I think I agree with you for discrete product releases, but for ongoing SaaS and moreso PaaS, it's helpful for integrations to have some visibility on your roadmap. I'm might just write a hack workaround for some issue if I have a belief that in 2024 you'll solve X -- I've got bigger fish to fry. But if I know you've removed it from your roadmap and it was planned by me, I can put it on mine to resolve. Surprising me with features means more often than I care to admit I write something to solve a problem, use it for a few months, and then vendor comes out with a solution to it that's close enough and better supported so I toss out code -- with a roadmap I could have avoided overlapping efforts.

But I'm more on the operational side - so I care more than most about the integrations with lots of vendors, different PoV's may of course differ.

[Brian_K_White]

But that was the whole point. You never had any visibility into their roadmap.

You only evet had visibility into a daydream that changed. What good is, no scratch that, there is no good in knowing something that you only think you know. It's negative value. It's worse than knowing nothing at all. It doesn't matter how much you want to know, and how good it feels to have that want pacified.

Similarly, this is also why even if someone does publish a road map, you should ignore it and only deal with whatever exists as it exists right now. Make all decisions, including looking ahead, based on nothing but the current state.

[MereInterest]

By that same logic, if somebody tells me they will pick me up on the way to a movie, I should go there on my own because they aren’t here already. I should walk to the movies, because my car is not currently running and whether or not it starts is in the future.

There’s such a thing as trust. Tools, people, and groups that have shown themselves to be trustworthy may continue to be trusted. It is also reasonable to point out these shifts, so that others know when announcements should no longer be trusted.

[Brian_K_White]

That is hyperbole not exprapolation.

[latexr]

I feel you. You seem to be reasonable and empathetic and understand that sometimes priorities change and that an imperfect roadmap can still bring benefits over a hidden one. On the other hand, there are a lot of people who feel entitled to get anything you ever mentioned, even (especially) if they’re getting it for free, and managing those people when they complain is time consuming and drains your sanity. Both of which take your time and energy away from improving the product to all the reasonable people.

[skybrian]

For a mature product, I think it makes sense to set an expectation of stability - what you see is what you get and if it’s not good enough as-is, don’t use it.

I don’t think closing off all internal discussion of future improvements necessarily the way to go, though? Sharing things like draft standards and programming languages enhancement proposals seems to work out pretty well.

Issue trackers, not so much. I think part of the problem is that the reply box is right there, inviting drive-by opinions, and makes it hard to keep things in perspective.

[jtj606]

As the post suggests - the GitHub community discussions are still the place to talk about these items. This is just closing the sometimes literally years old public roadmap posts.

What’s preferable, clarity on what’s actively planned, or ambiguity with dozens of features languishing on the public roadmap without any updates?

[eviks]

If you consider anything such a big issue, then your suggestion solves nothing - people still complaint, and now they also complaint about no transparency (see Apple)

> It’s exhausting having to deal with abuse on public forums when you’re on the receiving end and always have to keep your conposure.

What's so exhausting about ignoring like all of these corporates do?

[latexr]

> What's so exhausting about ignoring like all of these corporates do?

Maybe have some empathy for the people who have to interact with individual customers. There’s not an amorphous blob of “corporates” who deals with everything, there are real people with an life just as rich as yours on the other side.

[eviks]

Let's test your hypothesis on this issue: a "real person with rich life" posted a corporate statement and interacted 0 times with responses. Was that too exhausting?

[latexr]

We don’t need to go that far, we can test my hypothesis with this conversation. You are becoming exhausting and absolutely proving my point. I explained at length something that is clear and obvious to anyone who does customer support for any popular product. Instead of making an effort to be empathetic to the other side, you’re being contrarian and dismissive. Fortunately you’re not my customer and we’re not in my repo, so I have no obligation to continue this conversation.

The fact that the person on GitHub has not replied and the other conversations have been locked demonstrates that they are preemptively avoiding the exhausting interaction by limiting replies. Those are the actions of someone who knows the cause and effects of burnout. It is the opposite of ignoring, it is actively defensive. If you’re unable or unwilling to understand that, there’s nothing else I can say to you.

[mmsc]

Video game companies used to be like this. There was no community engagement, and the companies were essentially walled gardens. One day a feature (or even whole game!) would appear, and that would be the first you'd heard of it.

[nixpulvis]

There was a time when the dream of open source was healthy and strong. GitHub was a big part of the movement. So it shouldn't be surprising that they did more of their planning in the open than a company like Apple.

There are tradeoffs with secrecy. Trust me when I tell you, secrecy comes at a cost. It limits the flow of ideas, even within your own organization.

I'm tempted to agree with you anyways, since I've been in the situation before where we wanted to change things we were making while we were making them. You don't want to give off the impression that you don't know what you're doing.

Honestly, this kinda goes back to agile vs. waterfall too. It's all about defining requirements and meeting them.

[latexr]

> There are tradeoffs with secrecy. Trust me when I tell you, secrecy comes at a cost. It limits the flow of ideas, even within your own organization.

To clarify, I’m not advocating for active secrecy as goal, especially not inside the company. I’m more arguing for not actively sharing with the outside what you don’t have to because they don’t have the same context you do and will judge your decision out of their own biased feelings. Which then leads to you having to waste an inordinate amount of time explaining yourself.