The Gram Code Editor - 2026-05-15

krig: Since you've decided to close many issues even if they're not resolved (an understandable decision), I think it would be helpful to make sure that all closed issues have one of three labels: duplicate, resolved, or unresolved. That way, every bug or feature request has a canonical discussion point, and it's easy to find issues that aren't actually resolved if you're looking for something to work on.

I'd be happy to help with staying on top of that and filling in the backlog

krig: your project, your rules, but I think closing issues is not a good way to go if you'd accept PRs that would close them. Closing issues because you don't want a feature to be part of gram is logical, no problem with that. But if you'd accept a PR that fixes or implements what a ticket describe, then I think a dedicated tag is a much better way to go.

If someone wants to start contributing, opening the issue tracker and looking for opened issues to fix is generally how one starts. Issues are also a good venue to discuss a potential fix or feature before starting to work on it, to have an idea if it'd be accepted.

harper: I don't think the tags you proposed are meaningful enough. I'd suggest "wontfix" for things that wouldn't be accepted and should be closed, "contributions welcome" for things that krig don't want to work on but would accept a patch for, but they shouldn't be closed IMHO. ✏

hey, yeah I’m not happy about closing unresolved issues either and I don’t know what the best way forward is. I was considering turning off issues altogether, maybe that’s the way to go, Not sure. But the thing is, I do want to resolve every issue. I care about the project and want it to work. I am just completely unable to keep up. For me, gram is pretty much ”done” - it works for what I use it for. I don’t want to spend the rest of my life working on issues that I can’t reproduce or don’t really use. But the issues stress me out.

Maybe closing issues and opening the wiki is one way. Because this endlessly growing mix of feature requests and bugs is unsustainable for me

You can't expect to close all tickets by yourself, having opened tickets is fine? Bugless and feature-complete software does not exist?

I would argue that having opened tickets is a part of community-building.

Maybe "assign" tickets you want to close to yourself, this is what this forge feature is meant for IMHO.

yeah maybe you are right.

I was having a moment yesterday where it just got too much

but I guess the problem is my own expectation of myself

Yeah, FLOSS maintainer burnout is a thing indeed!

I can only speak for me, but I absolutely did not expect you to fix or implement the tickets I opened. Ofc, some users will be entitled and it is hard on the nerves. I hope I have not come up that way!

> I was having a moment yesterday where it just got too much you have been doing tremendous work, gram rocks, take it easy <3 ↺

❤️ I appreciate the work both you and @harper have been doing! I don’t want to come off like I don’t. What you’re saying makes sense. Maybe I need to view the backlog differently. But yeah better labels is one thing for sure. I don’t know if I want to label anything ”wontfix” though, if someone cares about it, it doesn’t interfere with other things and there’s a reasonable patch, I would want to merge it even if I had no plan to do it myself

ha! how about "implement github copilot integration"? that surely sounds like a "wontfix" to me ;)

OK that one is a wontfix, yes

fortunately we are immune to ”spend a week to vibe-rewrite in rust”

I understand not having enough time to maintain everything, and I respect setting boundaries for the project. But I think closing many issues might discourage contributors a bit. Sometimes people with free time just browse open issues looking for things to work on, and keeping some of them open could help community participation. Even if you don't plan to personally fix them, leaving some issues open with labels like “welcome contribution” could still be useful. From an outside perspective, this direction may feel somewhat more centralized compared to the original intent of Gram as a fork of Zed that aimed for a more open and less centralized model. Keeping issues open and allowing community contribution is a key part of that original idea, and reducing it significantly changes how the project is perceived and how contributors engage with it.

Hi, yeah I agree it’s a bit brutal to just mass close issues like this. Not sure how to get to a sustainable place without ruffling feathers though, the ever-increasing issue count was really starting to weigh on me. Especially the feature requests where I already know that I’ll never get to them. I started forgetting what the issues were and missed tagging things when I fixed them. But I guess it’s true that I do want to change the perception. I released this because I think it can be useful for others, but not to create a new job for myself. If someone wants to take it in a different direction I encourage that. I would love there to be as many forks as there are visions for what a good code editor can be.

but yeah the thing that broke me was trying to get it to build on windows via github actions, I shouldn’t have tried to solve that :p

ha now we know the bottom of it! it was microslop's fault all along 👿