Add contributor guidelines to development documentation

[Copilot]

The development documentation page was a placeholder ("coming soon..."). This PR populates it with a full contributor guide modeled after MNE-Python and Nilearn.

Changes

doc/documentation/development/index.rst

• Replaced placeholder with a proper development hub intro and toctree pointing to contributing, governance, and roadmap

doc/documentation/development/contributing.rst

• Full contributor guidelines covering:
  • Ways to contribute — code, docs, bug reports, tutorials, triage, PR review
  • Code style — PEP 8, Black, NumPy docstrings, optional pre-commit
  • PR process — fork → feature branch → dev install → test → submit → review loop
  • Issue reporting — bug report checklist (MRE, traceback, env details); enhancement proposals
  • Community standards — conduct expectations; references Contributor Covenant v2.1
  • Getting help — GitHub Discussions, Issues, lab website

Original prompt

Add contributor guidelines to the documentation page at documentation/development/index.md (shown at https://griffithslab.github.io/whobpyt/documentation/development/index.html).

The guidelines should be modeled after the contributor guides from established neuroimaging projects MNE-Python and Nilearn. Include the following sections:

1. Welcome Introduction: Invite contributions from anyone interested in whole-brain modeling and open source science. Link to issue tracker and discussions.
2. Ways to Contribute: Enumerate contributions like code, documentation, bug reports, tutorials, examples, issue triage, code review.
3. Code Style: Briefly describe or reference the preferred style (PEP8, black, docstrings). Mention use of pre-commit if relevant.
4. Pull Request Process: Steps for forking, creating feature branches, making and testing changes, submitting PRs, and what to expect.
5. Issue Reporting: How to report bugs (what info helps), how to suggest enhancements.
6. Community Standards: Adherence to a code of conduct (link to one if available or include basic expectation).
7. Getting Help: Where to ask questions (e.g., discussions, issues, email).

Format with appropriate headings, markdown list formatting, and links where applicable. Do not remove any useful existing content from the page. If content exists, please append or integrate clearly.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: make me some suggestions to improve the whobpyt website pages at https://github.com/griffithslab/whobpyt

Assistant: Here are some suggestions to improve the whobpyt website pages, based on best practices for open-source scientific software, typical user expectations, and standard GitHub Pages conventions:

1. Enhance the Project Landing Page (README.md)

• Clear Overview: Make the purpose, scope, and key features of whobpyt immediately clear in the first paragraph.
• Visuals: Add a project logo or diagram showing the modeling workflow.
• Quickstart Guide: Include a concise code example or snippet for a first-time user.
• Badges: Add status badges for build, PyPI, docs, DOI, and other relevant indicators.
• Links: Prominently link to the website/docs/demo notebooks.

2. Dedicated Website Content (Docs or GitHub Pages)

• User Documentation:
  • Installation instructions (pip/conda & dependencies).
  • In-depth usage examples (Jupyter notebooks demonstrating key use cases).
  • API Reference auto-generated from docstrings (use Sphinx or MkDocs).
  • Frequently Asked Questions (FAQ) for troubleshooting.
• Model Gallery: Show off model components, available simulations, and their biological/research significance—ideally with visual outputs/plots.
• Interactive Demos: If feasible, offer Binder/Colab links to run examples with one click.
• Citations & Publications: Guidance on citing whobpyt, list of research using it, and links to associated papers.
• Contributions: Section for contributors, code of conduct, and how to contribute.
• Tutorials: Step-by-step guides going from a simple model to a realistic brain simulation.

3. Navigation and Appearance

• Easy Navigation: Ensure there’s a clear menu/sidebar to access API, tutorials, model details, datasets, etc.
• Customization: Use your logo, consistent colors, and branding to make the site recognizable and professional.
• Contact: Provide ways to get help (Discussions, Support email, Slack/Discord link if relevant).

4. Technical Improvements

• Deploy Documentation: Use GitHub Actions to generate and deploy docs on every push (Sphinx, MkDocs, or Docsify).
• Live Examples: Integrate nbviewer or other notebook rendering for non-interactive preview of example notebooks.
• Performance Showcase: Share benchmarks or validation results, including reliability and speed compared to similar packages.

5. Community and Outreach

• Showcase Research: Gallery of published works that used whobpyt, preferably with figures.
• Roadmap: Page laying out planned features and updates.
• Changelog: Clearly visible changelog or release notes.
• Acknowledgments: Credit contributors, funders, and dependencies.

---

Would you like detailed example layouts or recommended open-source templates for any of these suggestions? If you have a specific doc generator (Sphinx, MkDocs, etc.), I can tailor guidance accordingly.

User: this is the built website fyi

https://griffithslab.github.io/whobpyt/

Assistant: Thank you for sharing your current built website: https://griffithslab.github.io/whobpyt/

Based on the typical layout and contents of scientific software documentation sites, and combining that with my previous suggestions, here is feedback specifically tailored to improving your whobpyt website:

---

Review & Suggestions for https://griffithslab.github.io/whobpyt/

1. Homepage Improvements

• Purpose and Overview
  Op...

This pull request was created from Copilot chat.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.