Add a README with a high-level roadmap#7
Conversation
README.md
Outdated
|
|
||
| The "minimal" milestones were about getting Zed to a point where the Zed team could use Zed productively to build Zed. What features are required for someone outside the company to use Zed to productively work on another project that is also written in Rust? | ||
|
|
||
| This includes infrastructure like auto-updates, error reporting, and metrics collection. It also includes some amount of polish to make the tool more discoverable for someone that didn't write it, such as a UI for updating settings and key bindings. |
There was a problem hiding this comment.
This includes infrastructure like auto-updates, error reporting, and metrics collection
It might be good to mention some other basic server-side concerns like signup, a permissions model, etc. Would those things also fall under this "Private alpha for Rust teams" phase? I think that for the internal collaborative phase, we might be able to punt on some of them.
There was a problem hiding this comment.
Good point, @maxbrunsfeld.
One related thought is: is there any non-code work that we would need by this phase, e.g. a logo, branding for the website/app, etc.?
Also, in terms of how the app looks, I'd be more than happy for internal use to have the editor look like Atom. That said, people are very excited about trying something that looks different (see yesterday's conversation about Dark Mode driving signups on StackOverflow) and sticking to it because of how it looks (in addition to the great performance we will offer). We should probably only provide one theme, but do we need to diverge from Atom's palette and, if so, when is the right time to do that? Alpha or private beta?
as-cii
left a comment
There was a problem hiding this comment.
Absolutely love this, nice work capturing it all so clearly! 💯
README.md
Outdated
|
|
||
| The "minimal" milestones were about getting Zed to a point where the Zed team could use Zed productively to build Zed. What features are required for someone outside the company to use Zed to productively work on another project that is also written in Rust? | ||
|
|
||
| This includes infrastructure like auto-updates, error reporting, and metrics collection. It also includes some amount of polish to make the tool more discoverable for someone that didn't write it, such as a UI for updating settings and key bindings. |
There was a problem hiding this comment.
Good point, @maxbrunsfeld.
One related thought is: is there any non-code work that we would need by this phase, e.g. a logo, branding for the website/app, etc.?
Also, in terms of how the app looks, I'd be more than happy for internal use to have the editor look like Atom. That said, people are very excited about trying something that looks different (see yesterday's conversation about Dark Mode driving signups on StackOverflow) and sticking to it because of how it looks (in addition to the great performance we will offer). We should probably only provide one theme, but do we need to diverge from Atom's palette and, if so, when is the right time to do that? Alpha or private beta?
This pull request enables users to set breakpoints by clicking to the left of a line number within editor. It also anchor's breakpoints to the original line they were placed on, which allows breakpoints to stay in their relative position when a line before a breakpoint is removed/added.
- Fix #4: ACP write_text_file now checks tool permissions for edit_file tool before writing. Deny patterns and default mode are respected. - Fix #5: ACP request_permission now checks always_deny/always_allow/always_confirm patterns using the tool call title as best-effort input for matching, instead of only checking the default mode. - Fix #7: Settings UI find_matched_patterns now tracks whether shell parsing succeeded and marks allow patterns as overridden when parsing fails, matching the real engine's behavior.
Replace all occurrences of 'default_mode' with the canonical 'default' field name. The old name only exists as a serde alias for backward compat.
V1 workspace-centric config: move config files to assets/config/, resolve tool paths with dir_has_content() to handle empty dirs, add package-protools build script. Bug fixes: - Empty directories no longer break tool path resolution (zed-industries#2) - Global hotkeys now call spawn_tool_entry() directly (zed-industries#5) - Hotkey config only re-registers when file content changes (zed-industries#1) - Remove redundant Plus (+) shortcut button (zed-industries#6) - Fix button text alignment to left (zed-industries#7) New feature: recent folders list below Pasta Ativa with click-to-switch and persistent storage in .pastas_recentes file. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Rendered
Here are my high-level thoughts on our roadmap for roughly the next year. I link out to tracking issues for the first two milestones, which we can populate with more detail.
@maxbrunsfeld @as-cii I'd love your feedback on this. Do you agree with this high-level plan? What am I missing? What else could we do? No pressure to give critique if you're on board, but I'd love to get to an explicit approval from both of you before we merge.
@ledwards Hopefully this can set some context for next week's meeting. Your feedback is welcome, too.