Transparency and Collaboration: The Need for Shared Design for Zed

[Angelk90]

Hi all,

I wanted to open a discussion about an issue that I feel is holding back Zed’s development and community engagement. I’ve noticed that while many of us are eager to contribute and propose new ideas, the Zed team seems to be very secretive about the design and future directions of the project. This has led to stagnation, with requests from users going unheard.

It’s understandable that the team wants to maintain control over the design, but without adequate disclosure, it becomes difficult for community members to collaborate in a meaningful way. The only interactions we see are through pull requests that aren’t always granted, leading to growing frustration among those who want to contribute.

Without a solid and shared design base, future development risks becoming chaotic and inconsistent. The lack of communication and transparency is undermining community trust and could cause us to miss out on important opportunities for innovation. It would be helpful if the Zed team could share their guidelines and vision, creating a space where ideas can be discussed and integrated.

I hope we can have a constructive conversation about how to improve the collaboration and get Zed back on track!

Thanks everyone for your attention.

@0x2CA, @Spoutnik97 In reference to #19877

Please vote/comment to express your opinion.

[ghost]

Not entirely related but close enough, i recently proposed something in the discord channel but might be worth bringing it up here as well; the publicly available zed channels on zed are sometimes used by the zed developers to collaborate with each other, and folks from the open source community can peep in to listen and watch, which is all good and nice. however there isn't a single channel that's open for us to speak and share projects without explicit permission given by the zed staff, that prevents us from the open source community to collaborate with each other on zed in zed. the proposed solution was that someone makes their own private channel, but that's far from ideal in the sense that the zed open source community are already present in the zed channels, you're now have to work on promoting and inviting people into your own channel, very much like opening your own discord community. It's delightful to always see people in the channels, but saddening that none of them are allowed to speak and share projects with each other:

[TheRedXD]

I completely agree with this. I think the Zed team should definitely have their goals be fully transparent, ideally features which are being worked on being posted publicly, rather than being worked on somewhere internally. Perhaps development could go even faster if people knew about what the Zed team wants to accomplish!

This would make it easier to contribute, as we would know what needs to be done. People wouldn't have to go in blindly and attempt to add something, spend their time, only for it to get denied due to the feature being either not in line with Zed's goals, or it being planned/being worked on already.

[Angelk90]

@nervenes and @TheRedXD : I totally agree. It's important for the Zed team to be transparent about their goals. Having public information about what features they're developing could speed up the development process. This would allow the community to contribute in a more targeted way, avoiding people working on projects that might not align with the team's vision or that are already in development.

Also, it would be great to have a dedicated space in the community where everyone can share ideas and projects without having to ask permission. This would encourage collaboration and make the environment more inclusive for everyone.

I would ask you to also comment on Discord, so that we can involve more people on these topics.

[ghost]

I think Zed could take inspiration from Mitchell in how he manages issue tracking and and overall open source contributions in ghostty, https://x.com/mitchellh/status/1852039089547309552

I'm doing something new (for me) with Ghostty: the issue tracker is only for actionable tasks. Features in the issue tracker are accepted and well-scoped. Bugs are reproducible. PRs must have an associated issue (no drive-by PRs). The issue tracker is not used for discussion.

The one main benefit of this is maintainers and contributors can open up the issues tab and dive into anything. Every single issue is ready to be worked on. People who open a PR referencing an issue can have very high confidence their PR will be accepted.

In past OSS projects I've either started or been part of, the issue tracker has become a mess of Q&A, stale bug reports, and enhancement discussion. Drive-by PRs put burden on maintainers because they may implement an interesting feature but an undesirable way and saying no feels bad.

I also really hate issue bots. "Issue stale type /go-fuck-yourself to keep it open" is a system I've hated from both sides as a user and maintainer. (Bots that simply do categorization are good bots) The pattern I'm doing with Ghostty means issues in the issue tracker are never stale.

This time, all discussion is encouraged to use GH discussions. Once a bug is reproducible or a feature is designed in a way I approve of, it is converted to an issue. Some discussion happens in Discord/IRC too but I encourage it to eventually move to GH so it can be indexed by search engines.

We've been doing this for only about a month now and only within the context of a small (~2000 people) private beta, but so far I've thoroughly enjoyed the change in project management from it.

I think Zed is suffering from the very same things Mitchell is critiquing here, and the ones mentioned by Angelk in this discussion. The issue tracker on Zed feels like a mess, a bunch of Q&A that should be taken in discussions, and a lot of non reproducible issues. Same with PRs, a lot of undisclosed drive-by PRs from the Zed team that likely took place internally, and many drive-by PRs from the open source community because there isn't really any clear roadmap to what people should and shouldn't work on.