You can not select more than 25 topics Topics must start with a chinese character,a letter or number, can include dashes ('-') and can be up to 35 characters long.

0000-template.md 4.2 kB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121
  1. # [RFC #0000] OpenIMSDK proposal template
  2. ## Meta
  3. [meta]: #meta
  4. - Name: (fill in the feature name: My Feature)
  5. - Start Date: (fill in today's date: YYYY-MM-DD)
  6. - Author(s): (Github usernames)
  7. - Status: Draft <!-- Acceptable values: Draft, Approved, On Hold, Superseded -->
  8. - RFC Pull Request: (leave blank)
  9. - OpenIMSDK Pull Request: (leave blank)
  10. - OpenIMSDK Issue: (leave blank)
  11. - Supersedes: (put "N/A" unless this replaces an existing RFC, then link to that RFC)
  12. ## 📇Topics
  13. - [\[RFC #0000\] OpenIMSDK proposal template](#rfc-0000-openimsdk-proposal-template)
  14. - [Meta](#meta)
  15. - [📇Topics](#topics)
  16. - [Summary](#summary)
  17. - [Definitions](#definitions)
  18. - [Motivation](#motivation)
  19. - [What it is](#what-it-is)
  20. - [How it Works](#how-it-works)
  21. - [Migration](#migration)
  22. - [Drawbacks](#drawbacks)
  23. - [Alternatives](#alternatives)
  24. - [Prior Art](#prior-art)
  25. - [Unresolved Questions](#unresolved-questions)
  26. - [Spec. Changes (OPTIONAL)](#spec-changes-optional)
  27. - [History](#history)
  28. ## Summary
  29. [summary]: #summary
  30. One paragraph explanation of the feature.
  31. ## Definitions
  32. [definitions]: #definitions
  33. Make a list of the definitions that may be useful for those reviewing. Include phrases and words that OpenIMSDK authors or other interested parties may not be familiar with.
  34. ## Motivation
  35. [motivation]: #motivation
  36. - Why should we do this?
  37. - What use cases does it support?
  38. - What is the expected outcome?
  39. ## What it is
  40. [what-it-is]: #what-it-is
  41. This provides a high level overview of the feature.
  42. - Define any new terminology.
  43. - Define the target persona: OpenIMSDK author, OpenIMSDK user, platform operator, platform implementor, and/or project contributor.
  44. - Explaining the feature largely in terms of examples.
  45. - If applicable, provide sample error messages, deprecation warnings, or migration guidance.
  46. - If applicable, describe the differences between teaching this to existing users and new users.
  47. ## How it Works
  48. [how-it-works]: #how-it-works
  49. This is the technical portion of the RFC, where you explain the design in sufficient detail.
  50. The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.
  51. ## Migration
  52. [migration]: #migration
  53. This section should document breaks to public API and breaks in compatibility due to this RFC's proposed changes. In addition, it should document the proposed steps that one would need to take to work through these changes. Care should be give to include all applicable personas, such as platform developers, OpenIMSDK developers, OpenIMSDK users and consumers of OpenIMSDK images.
  54. ## Drawbacks
  55. [drawbacks]: #drawbacks
  56. Why should we *not* do this?
  57. ## Alternatives
  58. [alternatives]: #alternatives
  59. - What other designs have been considered?
  60. - Why is this proposal the best?
  61. - What is the impact of not doing this?
  62. ## Prior Art
  63. [prior-art]: #prior-art
  64. Discuss prior art, both the good and bad.
  65. ## Unresolved Questions
  66. [unresolved-questions]: #unresolved-questions
  67. - What parts of the design do you expect to be resolved before this gets merged?
  68. - What parts of the design do you expect to be resolved through implementation of the feature?
  69. - What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?
  70. ## Spec. Changes (OPTIONAL)
  71. [spec-changes]: #spec-changes
  72. Does this RFC entail any proposed changes to the core specifications or extensions? If so, please document changes here.
  73. Examples of a spec. change might be new lifecycle flags, new `OpenIMSDK.toml` fields, new fields in the OpenIMSDKage label, etc.
  74. This section is not intended to be binding, but as discussion of an RFC unfolds, if spec changes are necessary, they should be documented here.
  75. ## History
  76. [history]: #history
  77. <!--
  78. ## Amended
  79. ### Meta
  80. [meta-1]: #meta-1
  81. - Name: (fill in the amendment name: Variable Rename)
  82. - Start Date: (fill in today's date: YYYY-MM-DD)
  83. - Author(s): (Github usernames)
  84. - Amendment Pull Request: (leave blank)
  85. ### Summary
  86. A brief description of the changes.
  87. ### Motivation
  88. Why was this amendment necessary?
  89. --->