Skip to content

Contributing to BGSTM

Thank you for your interest in contributing to BGSTM (Better Global Software Testing Methodology)! We welcome contributions from the community to help make this framework even better.

📋 Table of Contents

🤝 Code of Conduct

Our Pledge

We are committed to providing a welcoming and inspiring community for everyone. We expect all contributors to:

  • Be respectful and inclusive
  • Exercise empathy and kindness
  • Accept constructive criticism gracefully
  • Focus on what is best for the community
  • Show courtesy and respect towards others

Unacceptable Behavior

  • Harassment, discrimination, or offensive comments
  • Trolling, insulting, or derogatory remarks
  • Publishing others' private information
  • Any conduct that could be considered inappropriate in a professional setting

🎯 How Can I Contribute?

There are many ways to contribute to BGSTM:

1. Documentation Improvements

  • Fix typos, grammar, or formatting issues
  • Improve clarity and readability
  • Add missing information or examples
  • Translate documentation to other languages

2. Templates and Examples

  • Share your testing templates
  • Contribute real-world examples
  • Create new template variations
  • Improve existing templates

3. Methodology Enhancements

  • Suggest improvements to testing phases
  • Share best practices from your experience
  • Add new methodology guides
  • Enhance existing methodology documentation

4. Issue Reporting

  • Report bugs or inconsistencies
  • Suggest new features or improvements
  • Share feedback on existing content
  • Identify areas that need clarification

5. Community Support

  • Answer questions in issues
  • Help others understand the framework
  • Share your implementation experiences
  • Participate in discussions

🚀 Getting Started

Prerequisites

  • A GitHub account
  • Basic knowledge of Git and Markdown
  • Familiarity with software testing concepts (helpful but not required)

Setting Up Your Development Environment

  1. Fork the Repository 

    # Fork via GitHub UI, then clone your fork
git clone https://github.com/YOUR-USERNAME/BGSTM.git
cd BGSTM

  2. Create a Branch 

    git checkout -b feature/your-feature-name
# or
git checkout -b fix/your-fix-name

  3. Make Your Changes

  4. Edit documentation files (.md files)
  5. Add new templates in the docs/templates/ directory

  6. Add examples in the docs/examples/ directory

  7. Test Your Changes

  8. Preview Markdown files to ensure proper formatting
  9. Check that all links work correctly
  10. Verify that images display properly
  11. Ensure consistency with existing documentation style

📝 Pull Request Process

Before Submitting

  1. Check Existing Issues/PRs: Make sure your contribution isn't already being addressed
  2. Review Guidelines: Ensure your changes follow our style guidelines
  3. Test Thoroughly: Verify all changes work as expected
  4. Update Documentation: If applicable, update related documentation

Submitting Your PR

  1. Commit Your Changes 
    git add .
git commit -m "Brief description of your changes"

Use clear, descriptive commit messages: - Add: [description] for new features/content - Fix: [description] for bug fixes - Update: [description] for improvements - Docs: [description] for documentation changes

  1. Push to Your Fork 

    git push origin feature/your-feature-name

  2. Create Pull Request

  3. Go to the original BGSTM repository
  4. Click "New Pull Request"
  5. Select your fork and branch

  6. Fill out the PR template with:

    • Title: Clear, concise description
    • Description: What changes you made and why
    • Related Issues: Link any related issues
    • Testing: How you tested your changes

  7. PR Review Process

  8. Maintainers will review your PR
  9. Address any requested changes
  10. Once approved, your PR will be merged
  11. Your contribution will be credited

PR Requirements

  • ✅ Clear description of changes
  • ✅ Follows style guidelines
  • ✅ No broken links or formatting issues
  • ✅ Consistent with existing content
  • ✅ Appropriate file/folder structure
  • ✅ Professional and accurate content

📐 Style Guidelines

Markdown Formatting

  • Use consistent heading levels (#, ##, ###)
  • Use bullet points for lists
  • Use numbered lists for sequential steps
  • Use code blocks with language specification: 
    ```bash
# Your command here
```

Documentation Style

  • Clarity: Write clear, concise content
  • Consistency: Follow existing formatting patterns
  • Professionalism: Maintain a professional tone
  • Accuracy: Ensure technical accuracy
  • Examples: Include practical examples where appropriate

File Naming

  • Use lowercase with hyphens: test-planning.md
  • Be descriptive: agile-sprint-planning-template.md
  • Match existing naming conventions

Directory Structure

Maintain the existing structure: 

docs/
├── phases/           # Testing phase documentation
├── methodologies/    # Methodology guides
├── templates/        # Testing templates
├── examples/         # Practical examples
└── integration/      # Integration guides

Content Guidelines

  • Use American English spelling
  • Write in second person ("you") for instructions
  • Use active voice when possible
  • Include real-world examples
  • Add visual aids (diagrams, tables) when helpful
  • Keep paragraphs concise (3-5 sentences)

🐛 Issue Reporting Guidelines

Before Creating an Issue

  1. Search Existing Issues: Check if the issue already exists
  2. Check Documentation: Ensure it's not already addressed
  3. Gather Information: Collect relevant details

Creating an Issue

Use the following templates based on issue type:

Bug Report

**Description**: Brief description of the issue

**Location**: Path to file or section

**Expected Behavior**: What should happen

**Actual Behavior**: What actually happens

**Steps to Reproduce**:
1. Step one
2. Step two
3. ...

**Additional Context**: Any other relevant information

Feature Request

**Feature Description**: What feature you'd like to see

**Use Case**: Why this feature would be valuable

**Proposed Solution**: How you envision it working

**Alternatives Considered**: Other approaches you've thought about

**Additional Context**: Any other relevant information

Documentation Improvement

**Area**: Which documentation needs improvement

**Current State**: What's currently there

**Suggested Improvement**: What should be changed

**Reasoning**: Why this improvement is needed

Issue Labels

We use the following labels: - bug - Something isn't working correctly - enhancement - New feature or request - documentation - Documentation improvements - good first issue - Good for newcomers - help wanted - Extra attention needed - question - Further information requested

💬 Contact

Questions or Discussions

  • Issues: For bugs, features, or improvements
  • Discussions: For questions and community discussions (if enabled)

Getting Help

If you need help with your contribution:

  1. Check the documentation
  2. Review existing issues and PRs
  3. Open a new issue with the question label
  4. Be specific about what you need help with

🎉 Recognition

All contributors will be recognized for their contributions. We value every contribution, no matter how small!

Types of Contributions Recognized

  • Code/documentation contributions
  • Issue reporting and triage
  • Community support
  • Spreading the word about BGSTM

📚 Additional Resources

Thank You! 🙏

Your contributions help make BGSTM better for the entire software testing community. We appreciate your time and effort!

Happy Contributing! 🚀