Contributing to Swiss Marketing Marketplace¶

Thank you for contributing to our strategic planning repository. This guide will help maintain consistency and quality across all documentation.

🎯 Repository Purpose¶

This repository contains strategic business planning documents for a pre-seed stage startup. Unlike code repositories, our "contributions" are strategic insights, research updates, and business model refinements.

👥 Contributor Roles¶

Core Team¶

Can create and modify all documents
Responsible for version control and document quality
Make final decisions on business model changes

Strategic Advisors¶

Provide feedback and suggestions via pull requests
Can flag documents for review
Contribute market insights and validation data

Potential Investors¶

Read-only access to curated materials
Feedback collected through separate channels
NDA required for access

📝 Document Standards¶

Naming Conventions¶

Use clear, descriptive names:

✅ Good: Preseed_Lean_Business_Canvas_v1_0.md
✅ Good: Phase_3.1_Startup_Customer_Analysis.md
❌ Bad: canvas.md
❌ Bad: document123.md

Version numbering: - Major version (X.0.0): Significant strategic pivots or complete rewrites - Minor version (0.X.0): Substantial updates or new sections - Patch version (0.0.X): Small corrections or clarifications

Document Structure¶

Every major document should include:

# Document Title

**Version:** X.X
**Date:** YYYY-MM-DD
**Status:** Draft | Active | Reference | Deprecated
**Author(s):** Name(s)

## Executive Summary
[2-3 paragraphs maximum]

## [Main Content Sections]

## Appendix (if needed)

## Version History
| Version | Date | Changes | Author |
|---------|------|---------|--------|
| X.X | YYYY-MM-DD | Description | Name |

Markdown Best Practices¶

Headers:

# H1 - Document Title Only
## H2 - Major Sections
### H3 - Subsections
#### H4 - Detailed Points

Lists:

- Use bullet points for unordered lists
- Keep list items parallel in structure

1. Use numbered lists for sequential processes
2. Or when order matters

Tables:

| Column 1 | Column 2 | Column 3 |
|----------|----------|----------|
| Data 1   | Data 2   | Data 3   |

Emphasis:

**Bold** for important terms or key takeaways
*Italic* for emphasis or technical terms
`Code` for technical references or specific values

🔄 Workflow¶

Making Changes¶

Before You Start
Check if someone else is working on the same document
Review the current version and CHANGELOG
Understand the document's purpose and audience

Creating a Branch

git checkout -b feature/document-name-update

Making Edits
Update version number if substantial changes
Add entry to document's version history table
Update CHANGELOG.md if major/minor version change

Committing Changes

git add path/to/document.md
git commit -m "type: description

- Detail 1
- Detail 2

Affects: [Business Model | Research | Strategy]
Version: X.X.X"

Commit Message Types¶

feat: New document or major section added
update: Substantial changes to existing content
fix: Corrections or clarifications
docs: Documentation or meta-file updates
refactor: Reorganization without content changes
style: Formatting or style improvements

Pull Request Process¶

Create PR with clear description:

## Changes Made
- List of specific changes

## Rationale
- Why these changes were needed

## Impact
- Which business model elements are affected

## Review Checklist
- [ ] Version numbers updated
- [ ] CHANGELOG updated
- [ ] Cross-references checked
- [ ] Formatting consistent

Request Review
Tag appropriate team members
Provide context for changes
Link to supporting research or data
Address Feedback
Respond to all comments
Make requested changes
Re-request review when ready
Merge
Only core team can merge to main
Delete branch after merge
Update team on significant changes

📊 Quality Standards¶

Research Documents¶

✅ Include source citations
✅ Separate facts from assumptions
✅ Provide data sources and dates
✅ Note limitations or gaps
✅ Connect findings to business model

Business Model Documents¶

✅ Align with research findings
✅ Include quantitative assumptions
✅ Address major risks
✅ Connect to validation roadmap
✅ Reference core principles

Strategic Planning Documents¶

✅ Actionable and specific
✅ Include success metrics
✅ Realistic timelines
✅ Resource requirements clear
✅ Dependencies identified

🔍 Review Criteria¶

Before submitting any document for review, verify:

Content Quality¶

[ ] Information is accurate and up-to-date
[ ] Claims are supported by evidence or clearly marked as assumptions
[ ] Document serves its intended purpose
[ ] Appropriate level of detail for audience

Consistency¶

[ ] Aligns with core business principles
[ ] Consistent with other documents
[ ] No contradictions with validated findings
[ ] Terminology matches project glossary

Structure¶

[ ] Follows document structure template
[ ] Logical flow and organization
[ ] Appropriate headers and sections
[ ] Tables and lists formatted correctly

Mechanics¶

[ ] Spelling and grammar checked
[ ] Links work correctly
[ ] Images display properly (if any)
[ ] Version information complete

🚫 What Not to Commit¶

Never commit: - Actual financial projections with real numbers (keep in separate tools) - Personal contact information of potential customers or investors - Confidential term sheets or legal documents - Raw research data with identifiable information - Passwords, API keys, or credentials - Personal notes or draft fragments

Be careful with: - Names of specific investors or companies (use anonymized versions if needed) - Detailed competitive intelligence that could be sensitive - Internal team discussions about people or partners

📅 Regular Maintenance¶

Weekly¶

Review any open PRs
Update working documents with new insights

Monthly¶

Update CHANGELOG with significant progress
Review document status (Draft → Active → Reference)
Archive outdated documents

Quarterly¶

Comprehensive review of all Active documents
Update version numbers as needed
Consolidate learnings into core documents

🆘 Getting Help¶

Questions about: - Document structure → Check existing documents in same category - Business model decisions → Discuss with core team first - Technical git issues → See Git Help section below - Content disagreements → Create issue for discussion

🔧 Git Quick Reference¶

Common Commands¶

# Get latest changes
git pull origin main

# Create branch
git checkout -b feature/your-feature-name

# See what changed
git status
git diff

# Stage changes
git add path/to/file.md
git add docs/research/  # Add entire folder

# Commit with message
git commit -m "type: brief description"

# Push to remote
git push origin feature/your-feature-name

# Update your branch with main
git checkout main
git pull
git checkout feature/your-feature-name
git merge main

Useful Aliases (add to ~/.gitconfig)¶

[alias]
    st = status
    co = checkout
    br = branch
    cm = commit -m
    last = log -1 HEAD
    unstage = reset HEAD --

📖 Documentation Philosophy¶

We value: 1. Clarity over complexity 2. Evidence over assumptions (but document both) 3. Actionability over comprehensiveness 4. Iteration over perfection 5. Collaboration over individual brilliance

We avoid: 1. Documenting for documentation's sake 2. Premature optimization of documents 3. Disconnected research that doesn't inform strategy 4. Jargon without explanation 5. Documents that duplicate existing content

🎓 Learning Resources¶

Markdown¶

Git¶

Business Documentation¶

Lean Canvas: See docs/business-model/Building_Lean_Business_Canvas_Guide.md
Pitch Decks: See docs/strategic-planning/Investor_Pitch_Deck_Framework_v0.1.md

Questions or Suggestions?

This is a living document. If you have suggestions for improving our contribution process, please create an issue or discuss with the core team.

Last Updated: October 21, 2025