Add RFC for TiDE incubating project

rfc/2021-01-20-TiDE.md

@@ -0,0 +1,91 @@
+# Proposal: TiDE
+
+- Author(s): [@aylei](https://github.com/aylei), [@baurine](https://github.com/baurine), [@dragonly](https://github.com/dragonly) (in alphabetical order)
+- Last updated: 2021-01-20
+- Discussion at: https://github.com/pingcap/community/issues/389
+
+## Abstract
+
+TiDE is aimed to be the definitive IDE of any TiDB related projects. It should provide a convinient and consistent way of developing TiDB code.
+
+## Background
+
+TiDE was originally a TiDB Hackathon 2020 project which won the second prize. During the hackathon event, we found that this tool could potentially change the way people develop TiDB projects completely, just think about how IDE has changed the software developing process.
+
+Opensource software development is a long process, so we really want to make everyones life easier.
+
+## Proposal
+
+We propose to continue developing TiDE as a community incubating project, so that more people could join the development with their hands-on experience about how to use the tool to empower themselves. This can be a positive feedback-improvement loop with the help of the TiDB community.
+
+The developing process should be in two phases:
+
+1. In the first phase, the original authors in hackathon are responsible for refactoring the code into an extensible structure, and finish the core features.
+2. In the second phase, feature requests and pull requests are welcome from the community, which will help the project to graduate.
+
+We should also define some milestones:
+
+1. TiUP/kubectl utils encapsulated
+2. fully support daily TiUP usage for TiDB development
+3. contributing documentations done
+4. TiDB dashboard scaffolding
+5. TiKV coprocessor scaffolding
+
+## Rationale
+
+<!--
+A discussion of alternate approaches and the trade-offs, advantages, and disadvantages of the specified approach:
+- How other systems solve the same issue?
+- What other designs have been considered and what are their disadvantages?
+- What is the advantage of this design compared with other designs?
+- What is the disadvantage of this design?
+- What is the impact of not doing this?
+-->
+TiDB itself is a distributed database system, which is very hard to contribute to, even for an experienced engineering. TiDE should lower the entry level into the TiDB community.
+
+## Compatibility and Migration Plan
+
+<!--
+A discussion of the change with regard to the compatibility issues:
+- Does this proposal make TiDB not compatible with the old versions?
+- Does this proposal make TiDB not compatible with TiDB tools?
+    + [BR](https://github.com/pingcap/br)
+    + [DM](https://github.com/pingcap/dm)
+    + [Dumpling](https://github.com/pingcap/dumpling)
+    + [TiCDC](https://github.com/pingcap/ticdc)
+    + [TiDB Binlog](https://github.com/pingcap/tidb-binlog)
+    + [TiDB Lightning](https://github.com/pingcap/tidb-lightning)
+- If the existing behavior will be changed, how will we phase out the older behavior?
+- Does this proposal make TiDB more compatible with MySQL?
+- What is the impact(if any) on the data migration:
+    + from MySQL to TiDB
+    + from TiDB to MySQL
+    + from old TiDB cluster to new TiDB cluster
+-->
+
+## Implementation
+
+<!--
+A detailed description for each step in the implementation:
+- Does any former steps block this step?
+- Who will do it?
+- When to do it?
+- How long it takes to accomplish it?
+-->
+TiDE is implemented as a Visual Studio Code extension, which would efficiently leverage all vscode provided capabilities, with features tailored for TiDB repos.
+
+## Testing Plan
+
+<!--
+A brief description on how the implementation will be tested. Both integration test and unit test should consider the following things:
+- How to ensure that the implementation works as expected?
+- How will we know nothing broke?
+-->
+We should find some seeds users in TiDB community, and keep in touch with them. After each version published, we should anounce it in a dedicated slack channel, and collect feedbacks from real users. We should also add telemetry in the codebase, so that we could find out popular features.
+
+## Open issues (if applicable)
+
+<!--
+A discussion of issues relating to this proposal for which the author does not know the solution. This section may be omitted if there are none.
+-->
+None.