Skip to content

Commit d37a723

Browse files
ulivzulivz
committed
docs: init rfc process and template
1 parent 2b4adba commit d37a723

File tree

2 files changed

+152
-0
lines changed

2 files changed

+152
-0
lines changed

‎rfcs/README.md

Lines changed: 78 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,78 @@
1+
# UI-TARS-desktop RFCs
2+
3+
Most changes including bug fixes and documentation improvements can be handled through standard GitHub pull requests. However, substantial technical changes requiring cross-platform considerations (Windows/macOS/Linux) should follow this RFC process to ensure systematic design review.
4+
5+
## When RFC is Required
6+
7+
Consider initiating an RFC for changes involving:
8+
- Architectural modifications
9+
- Native API integrations
10+
- Cross-platform behavior changes
11+
- Major performance optimizations
12+
- Security-sensitive implementations
13+
- Breaking API changes
14+
15+
## RFC Lifecycle
16+
17+
### 1. Pre-Discussion
18+
- Open a GitHub Discussion thread for initial concept validation
19+
- Identify core maintainers (@mention platform specialists)
20+
21+
### 2. Draft Submission
22+
1. Fork https://github.com/bytedance/UI-TARS-desktop
23+
2. Copy `rfcs/template.md` to `rfcs/drafts/000-feature-name.md`
24+
3. Submit draft PR with [WIP] prefix
25+
26+
### 3. Technical Review Phase
27+
- Platform leads review for:
28+
- Windows compatibility
29+
- macOS security implications
30+
- Linux packaging impacts
31+
- Required checklist completion:
32+
- [ ] Performance analysis
33+
- [ ] Cross-platform testing strategy
34+
- [ ] Error handling documentation
35+
- [ ] Binary size impact
36+
37+
### 4. Final Comment Period
38+
- Freeze feature scope
39+
- Address final review comments
40+
- Require 2/3 maintainer approvals (including at least one platform specialist)
41+
42+
### 5. Implementation Tracking
43+
- Upon acceptance:
44+
- Create tracking issue with platform-specific tasks
45+
- Label with target version milestone
46+
- Assign platform implementation owners
47+
48+
### Status Transitions
49+
```mermaid
50+
graph TD
51+
A[Draft] -->|PR Submitted| B(Review)
52+
B -->|Approved| C[Accepted]
53+
B -->|Rejected| D[Archived]
54+
C -->|Implementation| E[Implemented]
55+
C -->|No activity in 30d| F[Stalled]
56+
F -->|Resumed| C
57+
```
58+
59+
## Key Modifications from Original Process
60+
1. Added platform specialist review requirements
61+
2. Extended review period for cross-platform analysis
62+
3. Mandatory platform-specific checklists
63+
4. Implementation tracking with ownership assignments
64+
5. Stalled state for resource management
65+
6. Visual workflow diagram
66+
67+
## Implementation Rules
68+
- RFC authors receive implementation priority
69+
- Platform-specific implementations must include:
70+
- Windows: MSI installer compatibility tests
71+
- macOS: Notarization validation
72+
- Linux: Snap/Flatpak packaging checks
73+
- Binary size monitoring required for native modules
74+
75+
## References
76+
Inspired by:
77+
- [Electron RFC Process](https://www.electronjs.org/blog/rfc-process)
78+
- [React Native Architecture Decisions](https://github.com/react-native-community/discussions-and-proposals)

‎rfcs/template.md

Lines changed: 74 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,74 @@
1+
- Start Date: 2025-01-28
2+
- RFC PR: (leave this empty)
3+
- Issue: (leave this empty)
4+
5+
# Summary
6+
7+
Brief explanation of the proposed change for UI-TARS-desktop.
8+
9+
# Basic example
10+
11+
If the proposal involves API changes or new component interactions, provide a concise code/usage example. Omit if not applicable.
12+
13+
# Motivation
14+
15+
Why is this change essential for UI-TARS-desktop? What specific problems does it address? What limitations or user pain points will it resolve? Focus on objective technical reasons rather than subjective preferences.
16+
17+
# Detailed design
18+
19+
Technical specification of the proposal including:
20+
- Architectural diagrams (if applicable)
21+
- Modified/new APIs
22+
- Data flow changes
23+
- Lifecycle impacts
24+
- Error handling strategies
25+
- Compatibility with existing TARS patterns
26+
- Platform considerations (Windows/macOS/Linux)
27+
28+
Provide sufficient detail for core maintainers to evaluate implementation feasibility.
29+
30+
# Drawbacks
31+
32+
Critical considerations including:
33+
- Increased binary size/performance impact
34+
- Maintenance complexity
35+
- Security implications
36+
- Cross-platform consistency risks
37+
- Developer experience impacts
38+
- Migration challenges for existing integrations
39+
40+
# Alternatives
41+
42+
What other approaches were considered? Include:
43+
- Third-party solutions
44+
- Partial implementations
45+
- Alternative architectural patterns
46+
- Status quo analysis
47+
48+
# Adoption strategy
49+
50+
How will this change be rolled out? Address:
51+
- Phased implementation plan
52+
- Backward compatibility measures
53+
- Deprecation timelines (if any)
54+
- Documentation updates
55+
- Testing requirements (unit tests, E2E scenarios)
56+
57+
# How we teach this
58+
59+
Educational aspects covering:
60+
- Updated API documentation strategy
61+
- Sample project updates
62+
- Tutorial integration points
63+
- Workshop/onboarding implications
64+
- Error message guidance
65+
- Debugging patterns for new features
66+
67+
# Unresolved questions
68+
69+
Open technical discussions needing resolution:
70+
- Unvalidated performance assumptions
71+
- Undecided implementation details
72+
- Third-party dependency risks
73+
- Platform-specific edge cases
74+
- Long-term maintenance ownership

0 commit comments

Comments
 (0)