Public Roadmap#4331
Conversation
There was a problem hiding this comment.
Pull request overview
Updates the repository’s public-facing planning and contribution guidance by expanding the roadmap and documenting a more detailed PR tracking/review workflow.
Changes:
- Expanded
roadmap.mdwith release milestone links, focus-area tables, and community contribution guidance. - Enhanced
contributing-workflow.mdwith updated commit/merge guidance, conflict-resolution guidance, and detailed GitHub Project tracking fields/status flow.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| roadmap.md | Adds a structured, up-to-date roadmap plus contributor guidance and links to milestones/releases. |
| contributing-workflow.md | Documents squash-merge expectations, conflict handling, and a detailed project-board workflow for PR tracking. |
|
Highly appreciated! |
|
|
||
| ``` | ||
| ┌────────────┐ ┌─────────────┐ ┌───────────────────────┐ ┌───────────────┐ ┌──────┐ | ||
| │ To triage │──────▶│ In progress │──────▶│ In review │──────▶│ In validation │──────▶│ Done │ |
There was a problem hiding this comment.
Does this render properly?
There was a problem hiding this comment.
Appears fine to me! Can you paste your screenshot if you see an issue?
There was a problem hiding this comment.
I see slight mis-rendering of the boxes
There was a problem hiding this comment.
The ▶ is not the same width as original ASCII characters (<128). It's wider than a space, so it messes up the alignment with the other lines.
| 2. **Keep Status current** — If you're the author, move your linked issue to `In review` when your PR is ready for feedback. | ||
| 3. **Respond promptly** — When status is `Waiting for customer` and the **`Author Attention Needed`** label is applied, the team is blocked on your response. Address the feedback, push the updates, **remove the `Author Attention Needed` label**, and move Status back to `In review` (or `In progress` for major rework) so reviewers know the PR is ready for another pass. | ||
| 4. **Flag API changes early** — Set **API Impact** appropriately so PM review can happen in parallel with code review. | ||
| 5. **Don't skip validation** — Even after approval, the PR stays in `In validation` until CI passes and any manual verification is complete. |
There was a problem hiding this comment.
The new PR pipeline should be able to run without maintainer intervention. In that case, can we ask that contributors leave their PRs in Draft until validation passes. We don't want PRs appearing ready for review without passing checks.
|
|
||
| | Feature | Status | ETA | | ||
| |---------|--------|-----| | ||
| | Connection pool performance improvements | Active | June 2026 | |
There was a problem hiding this comment.
Should these tables include a link to the parent Issue, where one exists?
|
|
||
| --- | ||
|
|
||
| ## Community Contributions |
There was a problem hiding this comment.
I think the remaining sections belong elsewhere, maybe in the CONTRBUTING.md file?
github-project-automation
Bot
moved this from In review
to Waiting for customer
in SqlClient Board
dlevy-msft-sql
left a comment
dlevy-msft-sql
left a comment
There was a problem hiding this comment.
I love this! I can't wait to get it in front of users and start iterating on their feedback!
| @@ -1,30 +1,131 @@ | |||
| # Microsoft.Data.SqlClient Roadmap | |||
There was a problem hiding this comment.
How do you get to this page? Do we need to update the readme too?
edwardneal
left a comment
edwardneal
left a comment
There was a problem hiding this comment.
Great to see, thanks.
I'm also conscious that some of my PRs work in the same area without having an associated issue. I'll write this up before proceeding with the next ones.
|
|
||
| 1. **Link your PR to an issue** — This ensures the PR appears on the project board and is tracked through the workflow. | ||
| 2. **Keep Status current** — If you're the author, move your linked issue to `In review` when your PR is ready for feedback. | ||
| 3. **Respond promptly** — When status is `Waiting for customer` and the **`Author Attention Needed`** label is applied, the team is blocked on your response. Address the feedback, push the updates, **remove the `Author Attention Needed` label**, and move Status back to `In review` (or `In progress` for major rework) so reviewers know the PR is ready for another pass. |
There was a problem hiding this comment.
I've never been able to actually do most of this - the list of labels applied to my PRs have always been read-only, and I can't set field values in the project board. I've assumed that this needs triage access. Do I need to do something differently?
|
|
||
| ### Status Transitions | ||
|
|
||
| When a reviewer leaves feedback that needs author action, they move the PR to `Waiting for customer` **and** apply the `Author Attention Needed` label. The author removes the label (and updates Status back to `In review`/`In progress`) once the feedback is addressed. |
There was a problem hiding this comment.
At one point I think there was a view that only reviewers should resolve their own feedback comments, is that still the case?
| - **New features from community PRs must be driven by creating a GitHub issue first.** Discuss the proposal in the issue before starting implementation. This helps avoid wasted effort and ensures alignment with project goals. | ||
| - **Community contributions must not derail the project roadmap.** We prioritize features and fixes according to our published milestones. PRs that conflict with or distract from active roadmap items may be deferred. | ||
| - **Our maintainers reserve the right to reject PRs** that do not meet the required criteria to qualify for review. This includes PRs that: | ||
| - Lack a corresponding approved issue |
There was a problem hiding this comment.
Is the approved issue the one which is meant to be approved in the Github Project?
| - Do not follow the project's coding standards and conventions | ||
| - Are missing adequate test coverage | ||
| - Conflict with work already in progress by the team | ||
| - **Bug fixes and small improvements** are generally welcome without a prior issue, but a linked issue helps us triage and prioritize your contribution. |
There was a problem hiding this comment.
Can we still have the requirement to open an issue to explain the intention of a change, instead of direct PRs?
Since reviews require time, and intentions specified in the issue would greatly help. Such a practice would allow for contributions to be reviewed effectively and efficiently and reduce cognitive overload on the reviewer. mssql-python has made this a mandatory requirement in their workflows. Something to consider.
paulmedynski
added
the
Author attention needed
No description provided.