User Feedback Guide

We value your feedback and want to make the Fairness Pipeline Development Toolkit better for everyone. This guide explains how to share your feedback and how we process it.

How to Provide Feedback

1. GitHub Issues

For specific bugs, feature requests, or detailed feedback:

2. GitHub Discussions

For questions, ideas, or community discussions:

  • Visit GitHub Discussions

  • Use appropriate categories:

    • Q&A: Ask questions about usage, implementation, or best practices

    • Ideas: Share ideas and discuss potential features

    • Show and Tell: Share your use cases, success stories, or integrations

    • General: General community discussions

3. Feedback Form

For structured feedback, you can use the feedback form below or create an issue using the feedback template.

Feedback Form

Your Information (Optional)

  • Name/Username:

  • Email: (optional, for follow-up if needed)

  • Organization: (optional)

Feedback Type

  • Bug Report

  • Feature Request

  • Documentation Improvement

  • Usability Concern

  • Performance Feedback

  • Integration Experience

  • General Feedback

Your Experience

What are you using the toolkit for?

  • Model validation and testing

  • Production monitoring

  • Research and experimentation

  • CI/CD integration

  • Other: ___________

How long have you been using the toolkit?

  • Just started

  • Less than 1 month

  • 1-3 months

  • 3-6 months

  • 6+ months

What Worked Well

What aspects of the toolkit did you find helpful or well-designed?

[Your response here]

Areas for Improvement

What aspects could be improved? What was confusing or difficult?

[Your response here]

Specific Suggestions

Do you have specific suggestions for improvements?

[Your response here]

Use Case Details

Please describe your specific use case:

[Your response here]

Additional Comments

Any other feedback, questions, or context:

[Your response here]

Feedback Review Process

1. Submission

  • Feedback is submitted via GitHub Issues or Discussions

  • All submissions are acknowledged within 48 hours

2. Triage

  • Feedback is categorized (bug, feature, documentation, etc.)

  • Priority is assigned based on:

    • Impact on users

    • Frequency of requests

    • Alignment with project goals

    • Implementation complexity

3. Review

  • Feedback is reviewed by maintainers

  • Community input is gathered via discussions

  • Technical feasibility is assessed

4. Response

  • Bugs: Fixed in next patch/minor release when possible

  • Features: Added to roadmap for consideration

  • Documentation: Updated in next documentation cycle

  • Questions: Answered in discussions or documentation

5. Implementation

  • High-priority items are scheduled for upcoming releases

  • Medium-priority items are added to the roadmap

  • Low-priority items are tracked for future consideration

6. Follow-up

  • Submitters are notified when their feedback is addressed

  • Release notes credit contributors when appropriate

Feedback Categories

Bug Reports

When to use: When something doesn’t work as expected

What to include:

  • Clear description of the issue

  • Steps to reproduce

  • Expected vs. actual behavior

  • Environment information

  • Minimal code sample

  • Error messages or tracebacks

Feature Requests

When to use: When you have an idea for a new feature or enhancement

What to include:

  • Clear description of the feature

  • Problem it solves or use case it addresses

  • Proposed solution

  • Example usage

  • Alternatives considered

Documentation Feedback

When to use: When documentation is unclear, incomplete, or incorrect

What to include:

  • Which document/page

  • What was unclear or missing

  • Suggested improvements

  • Context about what you were trying to do

Usability Feedback

When to use: When the toolkit is difficult to use or confusing

What to include:

  • What you were trying to accomplish

  • What was confusing or difficult

  • Suggestions for improvement

  • Your experience level

Performance Feedback

When to use: When you encounter performance issues

What to include:

  • Dataset size and characteristics

  • Operation that was slow

  • Expected vs. actual performance

  • Environment details

  • Profiling results (if available)

Best Practices for Feedback

Be Specific

  • Provide concrete examples

  • Include code samples when relevant

  • Describe your use case clearly

Be Constructive

  • Focus on the issue, not the person

  • Suggest solutions when possible

  • Explain the impact on your workflow

Search First

  • Check existing issues and discussions

  • Review documentation

  • Search closed issues for similar feedback

Provide Context

  • Include environment information

  • Describe your use case

  • Explain what you were trying to accomplish

Response Times

We aim to respond to feedback within:

  • Critical Bugs: 24 hours

  • High-Priority Issues: 48 hours

  • Feature Requests: 1 week

  • General Feedback: 1-2 weeks

  • Documentation: 1-2 weeks

Note: Response times may vary based on maintainer availability and issue complexity.

Recognition

We appreciate all feedback and contributions:

  • Contributors are credited in release notes when appropriate

  • Significant contributions may be highlighted in documentation

  • Community feedback helps shape the project roadmap

Questions?

If you have questions about providing feedback:

Thank you for helping improve the Fairness Pipeline Development Toolkit!