Skip to content

Commit b76a3ac

Browse files
abduljaleelabduljaleel
committed
\Add Follow the Sun Development pattern
- Addresses cross-timezone collaboration challenges in InnerSource - Provides structured handoff protocols and async-first practices - Level 1 (Initial) pattern ready for community validation - Fills identified gap in current pattern collection"
1 parent df52668 commit b76a3ac

File tree

3 files changed

+214
-0
lines changed

3 files changed

+214
-0
lines changed

‎README.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -93,6 +93,7 @@ Our mission
9393
* [Circle Communities](/patterns/1-initial/circle-communities.md) - *InnerSource adoption is slow in organizations due to limited understanding, engagement, and contextual relevance. Circle Communities address this by fostering synchronous conversations that build connections, close knowledge gaps, and cultivate collaboration and continuous learning.*
9494
* [Internal Developer Platform](/patterns/1-initial/internal-developer-platform.md) - *As InnerSource adoption increases throughout an organisation, it is not unusual that project teams start to face inefficiencies in scaling their efforts due to fragmented tooling, environments, and workflows. An Internal Developer Platform (IDP) provides a way to tackle this type of challenges through a centralized, self-service system that standardizes development environments and integrates tools to enhance consistency, collaboration, and developer productivity.*
9595
* [Document Architecture Decisions](/patterns/1-initial/document-architecture-decisions.md) - *InnerSource contributors often face challenges in grasping the system's design rationale, which can result in misalignment between maintainers, contributors, and stakeholders — potentially discouraging participation. To enhance decision-making and transparency, we recommend capturing architecture decisions and their consequences in a lightweight, accessible format to streamline onboarding, clarify decisions, and support long-term project sustainability.*
96+
* [Follow the Sun Development](patterns/1-initial/follow-the-sun-development.md) - *InnerSource projects with contributors across multiple timezones struggle with delayed feedback cycles, duplicated work, and contributor frustration from timezone barriers. By implementing "Follow the Sun" development practices with structured handoff protocols, comprehensive async documentation, and timezone-aware tooling, projects can maintain continuous momentum and inclusive global collaboration.*
9697
* [InnerSource Incentives and Disincentives](/patterns/1-initial/incentives-and-disincentives.md) - *Lack of awareness for incentives as well well as disincentives for InnerSource contribution decrease the chances of an InnerSource project receiving contributions; this is addressed by sharing a comprehensive list of potential incentives and disincentives.*
9798
* [Walk the InnerSource talk](/patterns/1-initial/walk-the-innersource-talk.md) - *Teams across the organization are encouraged to adopt InnerSource principles such as working openly, sharing code, and collaborating transparently. But, if the team behind the InnerSource initiative doesn’t follow these practices themselves, it undermines credibility and adoption. Therefore, this team should lead by example: documenting their decisions as code, working in the open, and treating their work as an InnerSource project to build trust and show others how it’s done.*
9899
* [Require InnerSource before Open Source](/patterns/1-initial/innersource-before-open-source.md) - *Maintaining and managing open source projects can be challenging for organizations, due to a lack of internal infrastructure and people with the knowledge of the required collaboration practices. By requiring projects to be InnerSource before becoming open source, teams have time to establish the necessary internal support, governance, and collaboration skills needed for successful community engagement.*

‎WARP.md‎

Lines changed: 99 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
# WARP.md
2+
3+
This file provides guidance to WARP (warp.dev) when working with code in this repository.
4+
5+
## Common Development Commands
6+
7+
### Linting and Validation
8+
9+
```bash
10+
# Run markdown linting on all markdown files
11+
markdownlint "**/*.md"
12+
13+
# Validate pattern syntax for structured and validated patterns
14+
markdownlint -r ./.github/lint-pattern-syntax/pattern-template.js -c ./.github/lint-pattern-syntax/pattern-template.yml patterns/2-structured/*.md patterns/3-validated/*.md
15+
16+
# Check all links in the repository
17+
# Note: This runs as part of CI, no local command available
18+
```
19+
20+
### Book Generation
21+
22+
```bash
23+
# Generate Table of Contents for English book (requires Ruby 2.6+)
24+
cd book/scripts/
25+
bundle install
26+
ruby generate_toc.rb en
27+
28+
# Generate ToC for other languages (replace 'ja' with desired language code)
29+
ruby generate_toc.rb ja
30+
```
31+
32+
### Pattern Mind Map Generation
33+
34+
```bash
35+
# Generate interactive mind map visualization of patterns
36+
cd pattern-categorization/
37+
npm install
38+
# Mind map generation runs via GitHub Actions workflow
39+
```
40+
41+
## Repository Architecture
42+
43+
### Pattern Organization Structure
44+
45+
The repository uses a three-tier maturity system for organizing patterns:
46+
47+
- **`patterns/1-initial/`** - Initial patterns and "donuts" (patterns with missing sections)
48+
- **`patterns/2-structured/`** - Complete patterns following the template structure
49+
- **`patterns/3-validated/`** - Validated patterns with multiple known instances
50+
51+
### Content Flow Pipeline
52+
53+
1. **Pattern Creation**: Authors create patterns following the `meta/pattern-template.md` structure
54+
2. **Validation**: Patterns undergo syntax validation via custom markdownlint rules
55+
3. **Book Publishing**: Structured (Level 2) and Validated (Level 3) patterns are automatically included in the published book at patterns.innersourcecommons.org
56+
4. **Multi-language Support**: Content is translated and published in multiple languages (EN, JA, ZH, PT-BR, GL, ES)
57+
58+
### Key Components
59+
60+
- **`book/scripts/generate_toc.rb`** - Ruby script that extracts pattern titles and patlets to auto-generate book table of contents
61+
- **`.github/workflows/`** - Complete CI/CD pipeline including pattern validation, book generation, link checking, and multi-language processing
62+
- **`meta/`** - Contains contributor guidelines, pattern templates, and governance documentation
63+
- **`pattern-categorization/`** - Mind map visualization system using markmap for pattern discovery
64+
65+
### Pattern Template Structure
66+
67+
All structured patterns must include these sections:
68+
- **Title**: Memorable, concise, descriptive name
69+
- **Patlet**: 1-2 sentence problem/solution summary
70+
- **Problem**: Crisp problem definition
71+
- **Context**: Pre-conditions and applicability constraints
72+
- **Forces**: Trade-offs and changeable constraints
73+
- **Solutions**: Verified resolutions
74+
- **Resulting Context**: Post-solution situation
75+
- **Known Instances**: Real-world validation examples
76+
77+
### Quality Gates
78+
79+
- **Markdownlint**: Standard markdown formatting validation
80+
- **Pattern Syntax Validation**: Custom rules ensuring pattern template compliance
81+
- **Link Checker**: Validates all external references
82+
- **Spelling & Style**: Vale-based content quality checks
83+
84+
### Multi-language Workflow
85+
86+
The repository supports internationalization with automated workflows:
87+
- English patterns in `/patterns/` are the canonical source
88+
- Translations stored in `/translation/<language-code>/patterns/`
89+
- Book generation supports multiple languages via parameterized Ruby scripts
90+
- GitHub Actions generate separate books for each supported language
91+
92+
### Pattern Maturity Progression
93+
94+
Patterns advance through maturity levels with specific requirements:
95+
- **Level 1**: Readable content, basic validation
96+
- **Level 2**: Template compliance, style guide adherence, at least 1 known instance
97+
- **Level 3**: Multiple validation instances, thorough review, visual illustrations
98+
99+
This structure enables the InnerSource Commons community to collaboratively develop, validate, and publish best practices while maintaining quality standards and multi-language accessibility.

‎patterns/1-initial/follow-the-sun-development.md‎

Lines changed: 114 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,114 @@
1+
## Title
2+
3+
Follow the Sun Development
4+
5+
## Patlet
6+
7+
InnerSource projects with contributors across multiple timezones struggle with delayed feedback cycles, duplicated work, and contributor frustration from timezone barriers. By implementing "Follow the Sun" development practices with structured handoff protocols, comprehensive async documentation, and timezone-aware tooling, projects can maintain continuous momentum and inclusive global collaboration.
8+
9+
## Problem
10+
11+
InnerSource projects that span multiple timezones face significant collaboration challenges that reduce contribution velocity and contributor satisfaction. Contributors in different timezones experience long wait times for reviews, feedback, and guidance, leading to decreased engagement and project momentum.
12+
13+
## Story
14+
15+
A global technology company launched an InnerSource platform project with potential contributors from their offices in San Francisco, London, and Singapore. Initially, the project maintainers (based in San Francisco) would review contributions during their working hours, leaving contributors in other timezones waiting 12-16 hours for basic feedback. European contributors would submit pull requests before their weekend, only to find conflicts and questions on Monday morning that had been resolved by the US team during the weekend. Singapore-based developers felt excluded from architectural decisions that happened during US-Europe overlapping hours. After six months, 70% of contributions came from US timezones despite global talent availability.
16+
17+
## Context
18+
19+
- An InnerSource project has potential contributors across multiple timezones (3+ timezones spanning more than 12 hours)
20+
- The project receives regular contributions and requires frequent collaboration between maintainers and contributors
21+
- Traditional synchronous collaboration methods (meetings, real-time code reviews) create bottlenecks
22+
- Contributors in non-primary timezones report feeling excluded or delayed in their contribution efforts
23+
- The organization values global collaboration and wants to leverage distributed talent
24+
25+
## Forces
26+
27+
- **Synchronous vs. Asynchronous Balance**: Real-time collaboration provides immediate feedback and builds relationships, but creates timezone barriers. Pure async communication can lack nuance and slow decision-making.
28+
- **Documentation Overhead vs. Efficiency**: Comprehensive async documentation takes time to create and maintain, but is essential for timezone handoffs and onboarding.
29+
- **Local Autonomy vs. Global Consistency**: Giving timezone-specific teams decision-making authority improves speed, but can lead to inconsistent approaches across regions.
30+
- **Inclusive Participation vs. Decision Speed**: Ensuring all timezones can contribute to important decisions takes longer but builds stronger global community.
31+
- **Tooling Investment vs. Simplicity**: Timezone-aware tools and automation require upfront investment but significantly improve collaboration efficiency.
32+
33+
## Solutions
34+
35+
Implement a "Follow the Sun" development model that enables continuous project momentum through structured timezone handoffs:
36+
37+
### Core Practices
38+
39+
1. **Structured Handoff Protocol**
40+
- Create timezone-specific "shift notes" in project wikis or shared documents
41+
- Use standardized handoff templates that include: work completed, blockers encountered, decisions pending, and next priorities
42+
- Establish clear handoff times (e.g., end of each region's working day)
43+
- Designate timezone champions who coordinate handoffs and ensure continuity
44+
45+
2. **Async-First Documentation Standards**
46+
- All architectural decisions documented with context using [Architecture Decision Records (ADRs)](./document-architecture-decisions.md)
47+
- Code review comments include sufficient context for async response
48+
- Meeting recordings and transcripts published within 24 hours
49+
- Decision rationale captured in issue trackers, not just decisions themselves
50+
51+
3. **Timezone-Aware Processes**
52+
- Stagger regular project meetings across different timezone combinations
53+
- Use asynchronous RFC processes for major decisions with minimum 72-hour comment periods
54+
- Implement "follow-up reviews" where contributors from other timezones can add input after initial reviews
55+
- Create timezone-specific office hours for informal collaboration
56+
57+
4. **Global Maintainer Model**
58+
- Distribute [Trusted Committer](../2-structured/trusted-committer.md) roles across key timezones
59+
- Cross-train maintainers to avoid single points of failure in any timezone
60+
- Rotate "primary contact" responsibilities across timezones for different project areas
61+
62+
### Supporting Tools and Automation
63+
64+
- Configure CI/CD pipelines for all timezones with appropriate notification settings
65+
- Use project dashboards that show current "active timezone" and relevant contacts
66+
- Implement chatbots or automation that can provide basic project information 24/7
67+
- Set up timezone-aware notification systems that respect local working hours
68+
69+
## Resulting Context
70+
71+
When successfully implemented, Follow the Sun development creates:
72+
73+
- **Continuous Project Momentum**: Work progresses around the clock as contributors in different timezones pick up where others left off
74+
- **Increased Global Participation**: Contributors from all timezones feel valued and able to meaningfully participate
75+
- **Improved Documentation Culture**: The necessity of async handoffs raises overall project documentation quality
76+
- **Reduced Time-to-Market**: 24-hour development cycles can accelerate feature delivery
77+
- **Enhanced Knowledge Distribution**: Cross-timezone collaboration spreads expertise across the global team
78+
79+
However, this approach also introduces new challenges:
80+
- Higher coordination overhead and process complexity
81+
- Increased documentation maintenance burden
82+
- Potential for miscommunication in handoffs
83+
- Need for greater discipline in async communication practices
84+
85+
These challenges may lead to related patterns like "Timezone-Aware Project Governance" or "Cross-Cultural InnerSource Communication."
86+
87+
## Known Instances
88+
89+
*This is a gap we've identified - we need real-world validation. Consider organizations like Microsoft, IBM, SAP, or other global companies that likely face this challenge.*
90+
91+
**Potential validation areas to research:**
92+
- Global open source projects (Kubernetes, React, etc.) that could provide analogous examples
93+
- Enterprise software companies with global development teams
94+
- Organizations that have documented "follow the sun" practices in traditional development
95+
96+
## Status
97+
98+
- Initial
99+
100+
## Author(s)
101+
102+
- Abdul Jaleel Kavungal
103+
104+
## Acknowledgments
105+
106+
- InnerSource Commons Pattern Working Group
107+
- Global development teams who face these challenges daily
108+
109+
## Alias
110+
111+
- 24/7 InnerSource Development
112+
- Continuous Global Collaboration
113+
- Timezone-Spanning Development
114+
- Round-the-Clock InnerSource

0 commit comments

Comments
 (0)