Skip to content

Commit 34614b3

Browse files
zanicarzanicar
committed
docs: Add process documents
- Add FDD Release Framework - Add Improvement Proposal Process - Add Incident Management Plan (sanitized) - Update Discrod link - Fix feature request discussions link - Fix improvement proposal links - Update improvement proposal date and version
1 parent 248773e commit 34614b3

File tree

6 files changed

+1137
-6
lines changed

6 files changed

+1137
-6
lines changed

‎.github/ISSUE_TEMPLATE/config.yml‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ contact_links:
77
url: https://github.com/Talus-Network/.github/security/advisories/new
88
about: Report security vulnerabilities privately (never use public issues)
99
- name: 💬 Community Support
10-
url: https://discord.gg/talus
10+
url: https://discord.com/invite/EvD9zyNhGd
1111
about: Get help from the community on Discord
1212
- name: 📖 Documentation
1313
url: https://docs.talus.network

‎.github/ISSUE_TEMPLATE/feature-request.yml‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ body:
99
value: |
1010
## Feature Request Process
1111
12-
**Important**: Most feature requests should start as [GitHub Discussions](../../discussions) to gather community input before creating formal requests.
12+
**Important**: Most feature requests should start as [GitHub Discussions](https://github.com/orgs/Talus-Network/discussions) to gather community input before creating formal requests.
1313
1414
Use this template for:
1515
- Internal business-driven feature requirements

‎.github/ISSUE_TEMPLATE/improvement-proposal.yml‎

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -8,11 +8,11 @@ body:
88
attributes:
99
value: |
1010
## Template Information
11-
- **Version**: 1.2.0
12-
- **Last Updated**: 2024-12-XX
13-
- **Process**: [FDD-Release Framework](https://github.com/Talus-Network/.github/blob/main/docs/fdd-process.md)
11+
- **Version**: 1.0.0
12+
- **Last Updated**: 2025-09-23
13+
- **Process**: [FDD-Release Framework](https://github.com/Talus-Network/.github/blob/main/FDD-RELEASE-FRAMEWORK.md)
1414
15-
All improvement proposals must follow our systematic evaluation process. See the IP Process documentation for detailed guidelines.
15+
All improvement proposals must follow our systematic evaluation process. See the [IP Process](https://github.com/Talus-Network/.github/blob/main/IP-PROCESS.md) documentation for detailed guidelines.
1616
1717
- type: textarea
1818
id: basic-information

‎FDD-RELEASE-FRAMEWORK.md‎

Lines changed: 167 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,167 @@
1+
# Feature Driven Development & Release Framework
2+
3+
This document describes Talus's development and release process, integrating Feature Driven Development (FDD) with our systematic release framework. It defines the interface between Product and Engineering teams and establishes clear workflows for bringing ideas from conception to production.
4+
5+
## Core Framework
6+
7+
### Pipeline Architecture
8+
9+
The FDD-Release framework operates through four sequential pipelines, each with clear ownership and deliverables:
10+
11+
| Pipeline | Release Phase | Interface Point |
12+
| ------------------------- | ------------------------------ | -------------------------------- |
13+
| Architecture Pipeline | Product Design Review | Strategic → Tactical Translation |
14+
| Feature Pipeline (Spec) | Technical Feasibility Analysis | Requirements → Implementation |
15+
| Feature Pipeline (Build) | Technical Implementation | Engineering Execution |
16+
| Feature Pipeline (Deploy) | Release | Engineering → Product Handover |
17+
18+
### Decision Gates
19+
20+
Each pipeline includes structured decision points with clear criteria:
21+
22+
- **Architecture Pipeline**: Strategic evaluation and IP approval process
23+
- **Feature Spec**: Technical feasibility and implementation planning
24+
- **Feature Build**: Quality assurance and pre-release validation
25+
- **Feature Deploy**: Release execution and stakeholder handover
26+
27+
## Development Process
28+
29+
### Phase 1: Architecture Pipeline - Strategic Alignment
30+
31+
**Dual-Stream Input** converging on formal **Improvement Proposals (IPs)**
32+
33+
#### Internal Stream (Strategic Initiatives)
34+
- Strategic RFC creation in internal planning systems
35+
- Leadership team evaluation for strategic fit and resource allocation
36+
- Business case validation and priority assessment
37+
38+
#### External Stream (Community Contributions)
39+
- Community discussions in GitHub Discussions
40+
- Technical RFC development for implementation approaches
41+
- Community consensus building and technical validation
42+
43+
#### Convergence Point
44+
Both streams converge at formal **IP creation on GitHub**, following our [Improvement Proposal Process](IP-PROCESS.md). All significant changes require IP approval before entering implementation.
45+
46+
**Deliverable**: Approved IP with strategic validation and technical feasibility confirmation
47+
48+
### Phase 2: Feature Pipeline (Specification) - Technical Translation
49+
50+
**Cross-functional collaboration** between Product and Engineering teams
51+
52+
- **Feature Design**: Detailed functional requirements and user acceptance criteria
53+
- **Technical Feasibility**: Implementation approach and dependency analysis
54+
- **Impact Assessment**: Downstream effects and integration requirements
55+
- **Spec Review**: Cross-functional approval and task breakdown
56+
57+
**Deliverable**: Detailed feature specifications with approved implementation tasks
58+
59+
### Phase 3: Feature Pipeline (Build) - Engineering Execution
60+
61+
**Engineering-led implementation** with defined quality gates
62+
63+
- **Implementation**: Code development following GitHub task breakdown
64+
- **Quality Assurance**: Comprehensive testing including unit, integration, and end-to-end testing
65+
- **Documentation**: Technical documentation and user-facing guides
66+
- **Pre-Release Preparation**: Infrastructure setup and deployment readiness
67+
68+
**Deliverable**: Tested, documented features ready for production deployment
69+
70+
### Phase 4: Feature Pipeline (Deploy) - Release & Handover
71+
72+
**Cross-functional release execution** with clear handover processes
73+
74+
- **Release Preparation**: Final validation and deployment coordination
75+
- **Production Deployment**: Coordinated release with monitoring and rollback procedures
76+
- **Stakeholder Handover**:
77+
- **DevRel**: Developer documentation and integration materials
78+
- **Product**: Feature validation and success metrics
79+
- **Marketing**: Communication materials and announcements
80+
81+
**Deliverable**: Successfully deployed features with complete stakeholder handover
82+
83+
## IP Integration
84+
85+
The Architecture Pipeline is implemented through our formal [Improvement Proposal Process](IP-PROCESS.md):
86+
87+
- **IP Creation**: All features begin with approved IPs, regardless of origin (internal/external)
88+
- **Technical Review**: Comprehensive evaluation of feasibility, impact, and implementation approach
89+
- **Comment Resolution**: Systematic resolution of all technical and strategic feedback
90+
- **Epic Generation**: Approved IPs automatically generate implementation epics
91+
92+
## Tool Integration
93+
94+
### Primary Development Tools
95+
96+
- **GitHub**: Issue tracking, project management, and technical coordination
97+
- **Internal Planning Systems**: Strategic planning and business case development
98+
- **Continuous Integration**: Automated testing and deployment pipelines
99+
100+
### Process Interfaces
101+
102+
- **IP Approval** → **Epic Creation**: Seamless transition from strategic approval to implementation planning
103+
- **Specification Completion** → **Task Generation**: Automatic breakdown into actionable development tasks
104+
- **Implementation Completion** → **Release Preparation**: Systematic handover to deployment processes
105+
106+
## Quality Standards
107+
108+
### Code Quality
109+
- Established coding standards for all supported languages
110+
- Comprehensive test coverage requirements
111+
- Automated code quality validation
112+
- Security review for sensitive components
113+
114+
### Process Quality
115+
- All changes tracked through formal IP process
116+
- Clear traceability from strategic need to deployed feature
117+
- Systematic documentation requirements
118+
- Stakeholder sign-off at each phase boundary
119+
120+
### Release Quality
121+
- Comprehensive pre-deployment testing
122+
- Coordinated release communication
123+
- Post-deployment monitoring and validation
124+
- Clear rollback procedures for issues
125+
126+
## Emergency Procedures
127+
128+
For critical fixes requiring immediate deployment:
129+
130+
1. **Emergency Epic Creation**: Using streamlined emergency epic template
131+
2. **Accelerated Review**: Essential quality gates with compressed timelines
132+
3. **Expedited Deployment**: Minimal viable process with full documentation
133+
4. **Post-Emergency Analysis**: Retrospective and process improvements
134+
135+
Emergency releases integrate with our [Incident Management Plan](INCIDENT-MANAGEMENT-PLAN.md) for coordinated crisis response.
136+
137+
## Process Benefits
138+
139+
### For Development Teams
140+
- **Clear Ownership**: Unambiguous responsibility at each phase
141+
- **Predictable Workflow**: Consistent process regardless of feature complexity
142+
- **Quality Focus**: Built-in quality gates prevent technical debt accumulation
143+
144+
### for Product Teams
145+
- **Strategic Alignment**: Direct connection between business needs and technical implementation
146+
- **Transparent Progress**: Real-time visibility into development status
147+
- **Coordinated Releases**: Systematic handover ensures proper launch execution
148+
149+
### For the Organization
150+
- **Scalable Process**: Framework adapts from small features to major releases
151+
- **Community Integration**: External contributions follow same quality standards
152+
- **Risk Management**: Systematic evaluation prevents costly mistakes
153+
154+
## Continuous Improvement
155+
156+
This framework evolves through:
157+
158+
- Regular retrospectives and process refinement
159+
- Community feedback integration
160+
- Tool optimization and automation
161+
- Best practice documentation and sharing
162+
163+
---
164+
165+
**Last updated**: 2025-09-23
166+
167+
*This framework is actively maintained and updated based on team feedback and organizational needs. For questions or suggestions about these processes, please open a discussion in the appropriate repository.*

0 commit comments

Comments
 (0)