1. Community Overview
2. Our Mission
3. Community Principles
4. Who Can Participate
5. Expected Conduct
6. Unacceptable Conduct
7. Professional Communication
8. GitHub Discussions Guidelines
9. Issue Reporting Guidelines
10. Pull Request Collaboration
11. Code Review Etiquette
12. Technical Disagreements
13. Community Decision-Making
14. Contributor Recognition
15. New Contributor Onboarding
16. Documentation Contributions
17. Responsible AI Development
18. Security and Responsible Disclosure
19. Privacy and Confidentiality
20. Spam and Promotional Content
21. Community Moderation
22. Reporting Community Concerns
23. Maintainer Responsibilities
24. Community Events and Initiatives
25. Recommended Community Workflow
26. Community FAQ
27. Official Resources
28. Final Community Commitment

EveryO is an open-source neural computing framework developed to make machine learning systems more understandable, accessible, and verifiable.

The community plays an important role in improving the framework through:

• Software development.
• Technical discussions.
• Research.
• Documentation.
• Testing.
• Bug reporting.
• Code review.
• Knowledge sharing.

Community participation should be constructive, transparent, and aligned with the project's technical objectives.

The EveryO community aims to:

1. Encourage meaningful open-source collaboration.
2. Maintain a respectful technical environment.
3. Improve framework correctness.
4. Support learning and experimentation.
5. Promote reproducible research.
6. Recognize useful contributions.
7. Protect users and contributors.
8. Maintain sustainable project governance.

These guidelines apply to participation in project-managed spaces, including:

• GitHub Issues.
• Pull Requests.
• Discussions.
• Code reviews.
• Documentation collaboration.
• Other official community spaces, if established.

Build an open environment where people can understand, improve, and experiment with neural computing technologies.

EveryO prioritizes:

• Readable implementations.
• Correct mathematical behavior.
• Transparent numerical operations.
• Reproducible experiments.
• Accessible documentation.
• Responsible engineering.

             EVERYO COMMUNITY
                    |
        +-----------+-----------+
        |           |           |
        v           v           v
      LEARN       BUILD       SHARE
        |           |           |
        +-----------+-----------+
                    |
                    v
                 REVIEW
                    |
                    v
                 IMPROVE
                    |
                    v
             OPEN INNOVATION

Treat participants with dignity and professionalism.

Disagreement about code or technical decisions must not become personal hostility.

Welcome participants with different backgrounds, experiences, and skill levels.

Explain technical decisions and limitations accurately.

Work toward solutions that improve the project rather than individual recognition alone.

Take responsibility for submitted changes and correct mistakes when identified.

Do not fabricate:

• Benchmarks.
• Test results.
• Research findings.
• Implementation status.
• Security claims.

Prefer maintainable solutions over unnecessary complexity.

The EveryO community welcomes:

There is no general experience threshold for participating in discussions or submitting contributions.

First-time contributors are encouraged to begin with:

• Documentation improvements.
• Reproducible bug reports.
• Small tests.
• Focused fixes.

All participants must follow the applicable repository policies.

The project's Code of Conduct establishes expectations for respectful and constructive participation.

Examples include:

• Using welcoming language.
• Respecting differing viewpoints.
• Accepting constructive feedback.
• Demonstrating empathy.
• Focusing on the project's goals.
• Giving credit for contributions.

Contributors should:

1. Explain changes clearly.
2. Provide evidence for technical claims.
3. Respond constructively to reviews.
4. Avoid unnecessary personal criticism.
5. Respect maintainers' decisions.
6. Correct inaccurate information.

Prefer:

The current implementation fails this numerical test because the gradient is not reduced over the broadcast dimension.

Avoid:

This code is terrible and the author does not understand autograd.

Focus criticism on observable technical behavior.

The Code of Conduct and Repository Rules prohibit behavior that undermines safety, trust, or constructive collaboration.

• Harassment.
• Discrimination.
• Threats.
• Personal attacks.
• Trolling.
• Repeated disruption.
• Doxxing.
• Publishing private information.
• Unwanted sexual attention.
• Spam.
• Deceptive promotion.

Unacceptable repository activity includes:

• Malicious code.
• Credential harvesting.
• Undisclosed network activity.
• Unauthorized telemetry.
• Fabricated test results.
• Misleading benchmarks.
• Incompatible licensing.
• Unreviewed bulk changes presented as verified.
• Repeated duplicate issues or pull requests.

Violations may result in moderation actions under the official Code of Conduct.

Use descriptive titles and explain the problem before proposing a solution.

Include:

• Relevant source files.
• Reproduction steps.
• Expected behavior.
• Actual behavior.
• Technical evidence.

When disagreeing, provide a technical explanation and, where possible, an alternative.

Do not assume another contributor's intent or experience.

GitHub Discussions is the recommended location for general community questions and broader technical conversations.

Open Discussions

• Framework usage.
• Design proposals.
• Architecture questions.
• Educational discussions.
• Research ideas.
• Community feedback.

1. Search existing discussions.
2. Review relevant documentation.
3. Choose an appropriate category.
4. Write a descriptive title.
5. Provide sufficient context.

# Discussion: Topic

## Background

Explain the context.

## Question or Proposal

Describe the main topic.

## Technical Details

Provide relevant information.

## Alternatives Considered

List possible approaches.

## Expected Outcome

Explain what feedback or decision is needed.

Keep discussions relevant to EveryO and its technical community.

GitHub Issues should be used for actionable, reproducible problems and tracked improvements.

Open Issues

• Search for duplicates.
• Confirm the problem is reproducible.
• Check the documentation.
• Collect relevant environment information.
• Use the appropriate template.

Include:

• EveryO version.
• Python version.
• Operating system.
• Reproduction code.
• Expected behavior.
• Actual behavior.
• Error output.

Include:

• Problem statement.
• Proposed solution.
• Intended users.
• Alternatives.
• Compatibility implications.
• Testing requirements.

Avoid:

• Duplicate issues.
• Vague descriptions.
• Unsupported claims.
• Unrelated feature requests.
• Spam.

Pull requests are the primary mechanism for proposing source changes.

       Identify Improvement
                |
                v
          Open Discussion
          (if necessary)
                |
                v
         Create Branch
                |
                v
         Implement Change
                |
                v
          Run Tests
                |
                v
         Open Pull Request
                |
                v
          Code Review
                |
                v
       Revise If Necessary
                |
                v
         Maintainer Decision

A pull request should:

• Have a clear purpose.
• Remain focused.
• Include relevant tests.
• Preserve supported behavior.
• Update documentation when needed.
• Follow coding standards.

Changes to differentiable operations should include appropriate gradient verification.

Contributions should preserve the CPU-only baseline unless a deliberate architectural change has been approved.

Passing CI does not guarantee acceptance.

Code reviews should improve quality without discouraging contributors.

Reviewers should:

1. Understand the proposed change.
2. Check correctness.
3. Evaluate test coverage.
4. Identify compatibility risks.
5. Explain requested changes.
6. Avoid unnecessary personal criticism.

Contributors should:

1. Read review comments carefully.
2. Ask for clarification when needed.
3. Address relevant concerns.
4. Explain technical trade-offs.
5. Avoid dismissive responses.

The new operation appears correct for equal-shaped inputs, but broadcasting cases need finite-difference gradient tests before merging.

Technical disagreements are normal in open-source development.

1. Define the disputed behavior.
2. Identify project requirements.
3. Present evidence.
4. Compare alternatives.
5. Discuss trade-offs.
6. Seek a practical resolution.
7. Respect the final governance decision.

Useful evidence includes:

• Reproducible tests.
• Benchmarks.
• Numerical comparisons.
• Documentation.
• Compatibility analysis.

Do not interpret disagreement with a proposal as a personal rejection.

Unresolved architectural disagreements may be referred to the project maintainer.

EveryO follows a maintainer-led governance model.

The maintainer is responsible for:

• Technical direction.
• Release decisions.
• Contribution acceptance.
• Repository management.
• Policy enforcement.

Community feedback is welcome through issues, discussions, and pull requests.

Decisions may consider:

• Correctness.
• Maintainability.
• Security.
• Compatibility.
• Project scope.
• Available maintenance capacity.

The maintainer retains final authority under the official governance policy.

Contributions do not automatically grant elevated repository permissions.

EveryO values meaningful contributions.

Recognition may include:

• Code contributions.
• Documentation.
• Tests.
• Reviews.
• Bug reports.
• Technical discussions.

Contributors should receive accurate credit for their work.

Git supports co-author attribution in commits.

Example:

Co-authored-by: Contributor Name <[email protected]>

Only use co-author attribution with the contributor's permission and for genuine contributions.

• Do not fabricate contributions.
• Do not manipulate contribution statistics.
• Do not create artificial pull requests for recognition.
• Do not claim authorship of another person's work.

Contributor spotlights or recognition initiatives may be proposed, but are not established by this document.

EveryO on GitHub

Review:

• README.md
• CONTRIBUTING.md
• CODE_OF_CONDUCT.md
• REPOSITORY_RULES.md
• GOVERNANCE.md

git clone https://github.com/krishanth7/EveryO.git

cd EveryO

python -m venv .venv

Activate the virtual environment.

Then install development dependencies:

python -m pip install -e ".[dev]"

python -m pytest -q

ruff check .

ruff format --check .

Choose a focused issue matching your experience.

Describe the change and provide testing evidence.

Documentation is an important part of EveryO.

• Correcting inaccurate explanations.
• Improving installation instructions.
• Adding runnable examples.
• Clarifying API behavior.
• Documenting limitations.
• Fixing broken links.

Documentation should be:

• Accurate.
• Clear.
• Consistent.
• Accessible.
• Technically reproducible.

Examples should use real EveryO APIs.

Avoid:

• Invented functions.
• Unsupported parameters.
• Fabricated output.
• Unverified benchmark claims.

Wiki improvements should be reviewed against the repository's source code and official documentation.

EveryO is a neural computing framework, and its community should promote responsible experimentation.

Contributors should report:

• Experimental setup.
• Data assumptions.
• Evaluation methods.
• Limitations.
• Reproducibility constraints.

Use datasets in accordance with their licenses and applicable privacy requirements.

Avoid claiming perfect accuracy or universal model performance without evidence.

Provide:

• Seeds.
• Software versions.
• Dataset details.
• Hyperparameters.
• Evaluation procedures.

Do not introduce malicious behavior, credential harvesting, or unauthorized data transmission.

Clearly distinguish experimental results from established functionality.

Security issues require special handling.

Use:

GitHub Private Vulnerability Reporting

Do not post:

• Exploit details.
• Sensitive attack instructions.
• Confidential vulnerability reports.
• Private credentials.

Provide:

• Affected component.
• Relevant version.
• Reproduction steps.
• Security impact.
• Suggested mitigation, if available.

Refer to:

SECURITY.md

Do not publish another person's private information without authorization.

Never commit:

• Passwords.
• API tokens.
• Private keys.
• Access credentials.

Do not upload confidential datasets or internal company information to public issues.

Remove sensitive information before sharing logs.

Contributors should understand the privacy implications of any new external integration.

The repository rules prohibit spam and deceptive promotional activity.

• Repeated duplicate issues.
• Irrelevant advertising.
• Automated promotional comments.
• Artificial contribution activity.
• Misleading project endorsements.

A link to another project may be useful when it directly supports a technical discussion.

A genuine technical contribution should provide demonstrable value to EveryO.

Do not manipulate stars, issues, pull requests, or review activity to create a misleading impression of popularity.

Moderation helps maintain a safe and productive environment.

• Protect participants.
• Enforce community standards.
• Prevent disruption.
• Maintain technical discussion quality.

Depending on the circumstances and the official Code of Conduct, maintainers may:

• Request changes in behavior.
• Remove inappropriate content.
• Restrict participation.
• Temporarily or permanently ban participants.

Moderation decisions should consider severity, context, and repeated behavior.

Sensitive reports should be handled with appropriate confidentiality.

The official Code of Conduct defines the enforcement framework.

Use the reporting mechanism identified in the repository's Code of Conduct.

Read the Code of Conduct

Use private vulnerability reporting.

Use GitHub Issues.

Use GitHub Discussions.

Include relevant context while avoiding unnecessary disclosure of private information.

Maintainers play a central role in community health.

• Review contributions.
• Maintain repository quality.
• Manage releases.
• Evaluate architectural changes.
• Preserve project consistency.

• Apply policies consistently.
• Encourage constructive discussion.
• Respond to concerns appropriately.
• Communicate technical decisions clearly.

Where appropriate, maintainers should explain significant technical decisions.

Maintainers are not required to accept every contribution or provide unlimited support.

Refer to:

GOVERNANCE.md

The following are potential community initiatives rather than confirmed existing programs.

• Beginner contribution sessions.
• Documentation improvement drives.
• Numerical correctness workshops.
• Open-source mentoring.
• Architecture discussions.
• Testing and benchmarking events.

Community activities should be:

• Inclusive.
• Technically meaningful.
• Voluntary.
• Respectful.
• Transparent.

Any proposed event should identify organizers, scope, dates, and participation requirements before being announced.

             COMMUNITY MEMBER
                    |
                    v
            Explore Repository
                    |
                    v
              Read Policies
                    |
                    v
             Identify a Need
                    |
          +---------+---------+
          |                   |
          v                   v
       Question             Code Change
          |                   |
          v                   v
      Discussion             Issue / PR
          |                   |
          +---------+---------+
                    |
                    v
             Technical Review
                    |
                    v
              Resolution
                    |
                    v
            Shared Knowledge

Healthy collaboration is measured through:

• Useful contributions.
• Reproducible results.
• Clear documentation.
• Respectful reviews.
• Sustainable maintenance.

Raw activity counts alone are not sufficient indicators of project quality.

The EveryO community is built on open collaboration, technical integrity, and mutual respect.

Every contribution should help improve the framework or the experience of its users and contributors.

Our shared objectives are to:

• Build reliable neural computing software.
• Encourage learning and experimentation.
• Maintain transparent technical practices.
• Respect contributors and users.
• Protect the integrity of the project.
• Support sustainable open-source development.

Great open-source software is built through careful engineering and meaningful collaboration.