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

TVM Roadmap RFC #50

Merged
merged 7 commits into from
Jan 18, 2022
Merged

TVM Roadmap RFC #50

merged 7 commits into from
Jan 18, 2022

Conversation

areusch
Copy link
Contributor

@areusch areusch commented Jan 7, 2022

No description provided.

This RFC proposes to add product roadmaps to TVM.

Roadmaps should be seen as a way of unifying the planning process of TVM, all the way from ideas to
PR merges. The roadmaps discussed in this pre-RFC are intentionally designed to integrate with TVM’s
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
PR merges. The roadmaps discussed in this pre-RFC are intentionally designed to integrate with TVM’s
PR merges. The roadmaps discussed in this RFC are intentionally designed to integrate with TVM’s

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

TVM: including vertical efforts involving TVM's intermediate representations (such as Relay or
TIR) and the horizontal efforts which span across TVM's full stack (such as Automation or
Documentation). Details about each of the components in TVM will be discussed later in this
pre-RFC.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
pre-RFC.
RFC.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done


This proposal includes two categories of roadmaps:

- **TVM Global Roadmap**: This roadmap aims to provide a holistic view of all components within TVM,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Is the global roadmap any different than the sum of the component roadmaps?
  2. How do we keep the global roadmap from falling into disrepair as teams update their own component roadmaps? a.k.a. who owns / drives it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@driazati, to answer your questions:

  1. The global roadmap is intended to be coarser-grained whereas the component roadmaps are intended to be finer-grained. If the tracking does ever overlap, both sets of roadmaps would be using the same base issues as roadmap items. For example, the TVM Global Roadmap and the TVM Automation Roadmap may both contain the AutoTIR tracking issue.
  2. In general, upon introduction of any new roadmap, we are requesting that there is at least one maintainer who volunteers to keep the roadmap up to date. For the TVM Global Roadmap specifically, we anticipate that this roadmap will be maintained by several active contributors within the TVM Community, and will address this further in the TVM Global Roadmap RFC.

and removing roadmap items. **Any community member can be listed as a maintainer of a roadmap,
regardless of contributor status within the Apache organization.**
- Note: If a Roadmap-RFC's proposed maintainer does not have TVM Committer or PMC status within
the Apache organization, they will receive an invitation for a Triage role in Apache TVM as soon
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding labels is a strong tool for organizing issues as they go into roadmap items, I think everyone that is a roadmap maintainer should have the triage role if nothing else, regardless of who else happens to be on the roadmap

to keep the roadmap concise. For example, if you have 10 flaky tests in CI, it might make sense
to have a global tracking issue for flaky CI tests which points to each individual bug.
![image|690x368](./assets/0050/roadmap-item-bugfix.png)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a category of mid-sized issues missing here that people generally don't file right now, but there is a lot of work not directly related to implementing an RFC or a bug fix that goes on (i.e. bigger than a bug fix but smaller than an RFC). I don't think there's any harm in making these into issues, even if they're not actionable/owned right away or if the ideas are less well formed (maybe the issue is just so a specific developer doesn't forget about something).

This would be nice with a wider application of the triage role since devs writing issues could assign it to themselves or mark it as triaged so it doesn't fill the queue.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a great callout. I agree that a roadmap's maintainers should have the ability to track these types of issues on the roadmap.

Perhaps this falls under Github Task-Tracking, and we should just change the wording so that we're not boxing that particular category in as "accepted RFCs only" - what are your thoughts @driazati @areusch?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that'd be good @denise-k, we've done this in the past to track future work arising from a PR review (for example: apache/tvm#8792) - this should serve as a reminder and incentive to follow up 😸

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I've added a mini-section here to address this.

Comment on lines 302 to 304
|TVM Roadmap M1A: Taking the Plunge|<li>All roadmap projects defined<br><li>Initial prototype roadmap (TVM CI & Testing) upstreamed <br> <li>Skeleton roadmap documentation upstreamed <br> <li>Scope of M1B and M1C clearly defined|Late September|
|TVM Roadmap M1B: Building Momentum|<li> At least 3 additional roadmaps upstreamed <br> <li> Additional roadmap process documentation upstreamed|Mid October|
|TVM Roadmap M1C: Ready for Prime Time|<li> All initial roadmaps (described in M1A RFC) upstreamed <br> <li> All RFC opens from M1A and M1B addressed <br><li> Publicize roadmap in documentation and TVM forums|Early November|
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These dates seem off

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

- **pre-RFCs** serve as a way to begin discussions on planned work at the earliest stage of
maturity. **pre-RFCs** are typically posted in the [TVM Discuss
forums](http://discuss.tvm.apache.org) in order to solicit TVM Community feedback. For an example
of a **pre-RFC**, see the screenshot of Andrew R's proposal to *Convert RST Docs to Markdown*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
of a **pre-RFC**, see the screenshot of Andrew R's proposal to *Convert RST Docs to Markdown*
of a **pre-RFC**, see the screenshot of @areusch's proposal to [Convert RST Docs to Markdown](https://discuss.tvm.apache.org/t/docs-discuss-convert-restructuredtext-docs-to-markdown/10264)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done, thanks!

@tqchen tqchen added the status: need review RFC needs review label Jan 10, 2022
Copy link
Member

@Mousius Mousius left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this @denise-k / @areusch! I have some a minor copy point about keeping GitHub consistent through-out and then some further questions but in general it makes sense to me 😸 It's definitely going to be interesting to see this in practice.


Roadmaps should be seen as a way of unifying the planning process of TVM, all the way from ideas to
PR merges. The roadmaps discussed in this pre-RFC are intentionally designed to integrate with TVM’s
existing planning tools (e.g. Github tracking issues, RFCs), while adding an additional space for
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
existing planning tools (e.g. Github tracking issues, RFCs), while adding an additional space for
existing planning tools (e.g. GitHub tracking issues, RFCs), while adding an additional space for

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Comment on lines 48 to 49
The roadmap utilizes Github Projects as the underlying tooling mechanism. This maximizes reuse of
existing content tracked in Github, and is very user-friendly for existing Github users.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The roadmap utilizes Github Projects as the underlying tooling mechanism. This maximizes reuse of
existing content tracked in Github, and is very user-friendly for existing Github users.
The roadmap utilizes GitHub Projects as the underlying tooling mechanism. This maximizes reuse of
existing content tracked in GitHub, and is very user-friendly for existing GitHub users.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

- **pre-RFCs** serve as a way to begin discussions on planned work at the earliest stage of
maturity. **pre-RFCs** are typically posted in the [TVM Discuss
forums](http://discuss.tvm.apache.org) in order to solicit TVM Community feedback. For an example
of a **pre-RFC**, see the screenshot of Andrew R's proposal to *Convert RST Docs to Markdown*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we expecting pre-RFCs to be this light weight? Following the same template as the eventual RFC both ensures people are considering the areas in the RFC process as well as starting the process of creating that eventual RFC document.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This came up in some of our previous discussions, and we've purposefully left this ambiguous because pre-RFC structures/guidelines are outside the scope of this RFC.

I do 💯 agree that there should be a set of guidelines for pre-RFCs, and I'd love to discuss this further. Perhaps it can be a topic in the next TVM community meeting! 😸

below.

**pre-RFCs** can be tracked on a Roadmap by preemptively creating a GitHub Task-tracking Issue
in [tvm-rfcs](https://github.com/apache/tvm-rfcs).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it not need to be in apache/tvm to enter the roadmap?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it doesn't need to be. The reason for this is because (for permissions reasons) the roadmaps will actually be created at the apache top level which can link to any repository within apache. Illustration below:

image


- **Github Task-Tracking Issues** are used in [tvm](https://github.com/apache/tvm) to share the
progress of accepted RFCs over time. For an example of a **Github Task-Tracking Issue**, see the
screenshot of Andrew L's RFC to *Add Mixed-Precision Support to TVM* below.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be good use the GitHub username here to illustrate which Andrew L further 😸

Copy link
Contributor

@denise-k denise-k Jan 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:%s/Andrew L's/@AndrewZhaoLuo's/g

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done!

to keep the roadmap concise. For example, if you have 10 flaky tests in CI, it might make sense
to have a global tracking issue for flaky CI tests which points to each individual bug.
![image|690x368](./assets/0050/roadmap-item-bugfix.png)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that'd be good @denise-k, we've done this in the past to track future work arising from a PR review (for example: apache/tvm#8792) - this should serve as a reminder and incentive to follow up 😸


Questions about the design and contents of the TVM Roadmap will be progressively resolved through
the upstreaming timeline shown above. Any unresolved questions at the end of TVM Roadmap Milestone 1
will be created as roadmap items in the TVM Community Roadmap 🙂
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The last character here doesn't render for me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a smile emoji; let's go ahead and remove it to avoid any rendering issues.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done!

roadmap functionality.

## Special Thanks
Thanks so much for copyediting, @areusch and @electriclilies! :hugs:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be @denise-k and @electriclilies given @areusch is the author here? 😸

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for bringing this up - I authored this initially (which is why I didn't refer to myself in third person), and @areusch ported it over to this RFC + made some additions. @areusch and I are already both listed as coauthors, so really it should be just @electriclilies listed as a copyeditor.

Roadmaps are defined using [GitHub
Projects](https://docs.github.com/en/issues/trying-out-the-new-projects-experience/about-projects)
and can include GitHub Issues, Pull Requests, and simple note cards. Maintainers should strive to
place mainly **GitHub Issues** in Roadmaps to make it possible for the community to learn more about
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
place mainly **GitHub Issues** in Roadmaps to make it possible for the community to learn more about
place mainly **GitHub Issues** in roadmaps to make it possible for the community to learn more about

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed!

@denise-k
Copy link
Contributor

@driazati @Mousius thanks for the reviews! I have addressed your comments and the PR is ready for a re-review.

Copy link
Contributor

@comaniac comaniac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you all folks for the efforts! The RFC looks good to me. From our previous experience of running RFCs (this repo), the overall approach and policy will get much more mature over time after we learned lessons from the real world, so I'm comfortable with the current plan, and we could always cycle back to make it better once we find anything missing.

@denise-k
Copy link
Contributor

Thanks @comaniac! I agree, it'll be good to have members of the community participate in creating roadmaps and making continuous improvements to the process.

@tqchen tqchen self-assigned this Jan 13, 2022
@tqchen
Copy link
Member

tqchen commented Jan 13, 2022

also cc @apache/tvm-committers to see if folks have more comments

@tqchen tqchen changed the title Add Roadmap RFC TVM Roadmap RFC Jan 13, 2022
Copy link
Member

@Mousius Mousius left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this @denise-k!

@areusch areusch added status: accepted RFC is accepted and removed status: need review RFC needs review labels Jan 18, 2022
@areusch areusch merged commit 263335f into apache:main Jan 18, 2022
@areusch
Copy link
Contributor Author

areusch commented Jan 18, 2022

thanks @Mousius @comaniac @denise-k @driazati for the reviews! Merging this and we'll move forward with the first individual Roadmap RFCs!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: accepted RFC is accepted
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants