Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we create a new "roadmap" repository to communicate the roadmap #104

Closed
iamsamirzon opened this issue Oct 13, 2021 · 4 comments
Closed
Labels
no_milestone To filter out issues we don't want to track in a milestone. question Further information is requested

Comments

@iamsamirzon
Copy link

There are different patterns used to communicate roadmaps. We need to decide how best to do this.

  1. Use a README.MD or ROADMAP.MD file inside the top level
    Pros : Simple to understand;
    Cons : After a while it becomes difficult to communicate fidelity in just a text document;
  2. Use a new repo, call it roadmap, and inside it use "Issues" to document and communicate roadmap items
    Pros : Allows use of "Github projects". Can use "labels" and "milestones" to track progress and do "Releases";
    Pros : This pattern is used by "Github", "Docker" to communicate their roadmaps
    Cons: Extra work on maintainers,
  3. Others

Additional Information
For Notary Project, both of the above patterns are attempted here : https://github.com/iamsamirzon/roadmap

@sudo-bmitch
Copy link
Contributor

I think this is now resolved: https://github.com/notaryproject/roadmap/projects/1

@dtzar
Copy link
Contributor

dtzar commented Jul 11, 2022

I believe we should utilize only the GitHub Project's beta board we now have to track everything, including the roadmap via the milestone assignments. Multiple views can be placed on top of the project board. We should migrate everything off of the roadmap repo to the individual repos and have "epics" and/or "user stories" with linked items to track higher-level value delivered to end users.

Having the separate roadmap repository is challenging because:

  1. Duplication of issues across projects - you have to have an issue in roadmap AND others
  2. Issues which pop-up in other repositories don't dynamically get factored into the plan, so then you have to go back and update roadmap repository.
  3. Milestones are assigned in the different repositories with different names and timelines which may or may not align with the roadmap. (This is now fixed/consistent in the projects beta board).

This is further complicated when adding in the google spreadsheet to try and track milestones. This also has been migrated to the projects beta board...

Overall, the separate roadmap repo is a lot of extra work to manage and adds more confusing.
If we're all good with what we have going with the projects beta board, I'd like to propose to close this out and retire roadmap repo and the spreadsheet. @iamsamirzon

@iamsamirzon
Copy link
Author

@dtzar - I agree with some of the challenges you have highlighted above but do think the roadmap repo serves a purpose that an auto generated project board may not provide. Specifically, the roadmap repo gives the maintainers and community a widely used pattern to set and provide visibility on the planned features at an epic/high level. A roadmap repo level item/issue typically represents work across multiple repos or dependency with other projects (such as ORAS) and ideally should not change more than once a quarter. A different view point for the challenges you listed above will be -

1 above) We expect duplication. A given roadmap repo issue will have one or more related issues across multiple repos. If we could have implementers easily link back to an item they are working to a roadmap repo issue we could achieve the N:1 mapping for traceability. I agree there is duplicate work required for this step, but it helps with separation of roles.

2 above) No dynamic addition/insertion of roadmap issues/items is a desired benefit. IMHO, roadmap repo gives a framework for the community to discuss the pros/cons of making a roadmap change Vs it happening via change in individual repos. It gives us an "intent driven" approach needed to accomplish a given "roadmap milestone".

3 above) Even after removing the roadmap repo, the challenge of using inconsistent milestone naming across different repos will still be there. On the contrary, the roadmap repo milestones names should be the ones used in other repos to align their individual work as it relates to the roadmap intent.

That said, I am open to moving away from the google spreadsheet we are using to track the granular work. It was a stop gap arrangement to accomplish alpha-3 and RC-1 implementation items in individual repo. I like the way you and others have added individual items in different repos. That was a lot of work and much needed. Thankful to you and others who tackled it. I have a few minor questions on how to traverse the project board and filter it to items we were tracking in the spreadsheet. that we can cover offline or time permitting in the meeting.

@dtzar
Copy link
Contributor

dtzar commented Jul 23, 2022

After further consideration and discussion with @iamsamirzon, @yizha1, @FeynmanZhou we have come to a consensus. We can keep the roadmap repo to have a centralized, controlled place, to help illustrate higher-level objectives which deliver value to users. Any of the implementation issues (specs, coding, etc) will be created in the associated repos (notation, notation-go, notation-core-go, notaryproject) and linked to on the description of the roadmap item to help track completion.

With this new schema and the project beta planning board, we also agreed that the roadmap, notation-api, notation-cli, and notaryproject labels no longer makes sense to utilize as this is self-evident.

Many of the roadmap items today currently do not fit this schema, so moving forward we will start to transform or close them to fit.
This is an example of the first item we migrated: notaryproject/roadmap#38

@dtzar dtzar closed this as completed Jul 23, 2022
@dtzar dtzar added question Further information is requested no_milestone To filter out issues we don't want to track in a milestone. labels Jul 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
no_milestone To filter out issues we don't want to track in a milestone. question Further information is requested
Projects
Status: Done
Development

No branches or pull requests

3 participants