# Contributor's Guide

Pygfx is a community effort, shaped by a group of contributors from around the
world. And you can contribute too!


## Creating issues, pull-requests, and discussions

We coordinate our work using GitHub,

* The [issues](https://github.com/pygfx/pygfx/issues) are meant to track problems and feature requests.
* The [pull-requests](https://github.com/pygfx/pygfx/pulls) (a.k.a. PR's) are used to contribute new code to the project.
* The [discussions](https://github.com/pygfx/pygfx/pulls) are to ask questions and have discussions related to (using) the project.

Before creating a new issues, please first search the issue list to see if your problem is
already known. If it is, you can then participate by letting us know you encountered the
same problem, and maybe add specific details that can help us fix the problem.

If you're new to Github, see Github's documentation for
[creating an issue](https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/creating-an-issue)
and [creating a pull-request](https://docs.github.com/en/get-started/using-github/github-flow).
And we are also here to help you!


## How can I contribute?

### Reporting problems

If you run into a difficulty when using Pygfx, we'd like to know, so that we can
fix or document it. If you encounter what you think is a bug, please let us
know by creating an issue! Likewise in case things are unclear, e.g. because the documentation is incomplete or
outdated.

### Asking questions

If you are trying to achieve something and you're not sure how to do this with Pygfx, you
can start a discussion. We can then give some tips, and others with similar
goals can benefit too.

### Requesting and contributing features

If you feel that something is missing, you can create an issue to request that
feature. We especially appreciate if you're willing to contribute the new
feature via a pull-request. It can be good to first open an issue (especially
for large/complex features) to discuss the approach and design. This
increases the chance of a successful pull-request.

### Promoting Pygfx

We love it when Pygfx is used in a derived project, blog posts, article, or scientific paper.
We love it even more if Pygfx is referenced to help increase the visibility of the project.
Also feel free to reach out to let us know!

### Active contributions

If you just want to help move the project forward, we welcome you to:

* Check the issue list, to see if there are issues that you can help with, maybe by fixing a bug or contributing a new feature.
* Check the pull-requests, to see if you can help review it, or maybe test it out.
* Check the discussions, to see if you can help answer user questions.
* Read the documentation, and see if it can be improved.


## AI Policy

*This policy was gratefully inspired by the AI policies of SciPy and scikit-image.*

We are a small developer team, and we enjoy reviewing and discussing code
written by other humans. We recognize that LLMs may be useful, but overall
prefer for contributions to be hand-written.

### Responsibility

You are responsible for all the code that you contribute, including the AI
generated code. You must understand and be able to explain the submitted code as
well as its relation with the surrounding code. It is not acceptable to submit a
patch that you cannot understand and explain yourself.

### Disclosure

You must disclose whether AI has been used to produce any code of your
pull-request. If so, you must document which tool(s) have been used, how they
were used, and specify what code or text is AI generated.

### Copyright

Contributors must own the copyright of any code submitted to Pygfx. Code
generated by AI may infringe on copyright and it is your responsibility to not
infringe. We reserve the right to reject any pull requests where the copyright
is in question.

### Communication

When interacting with developers (in discussions, issues, pull-requests,
etc.) do not use AI to speak for you, except for translation or grammar editing.
Human-to-human communication is essential for an open source community to
thrive.

### AI Agents

The use of an AI agent that writes code and then submits a pull request
autonomously is not permitted.


## Coding Style

The Pygfx project uses `ruff` to format and lint the code:

```bash
# Reformat the code if necessary
ruff format
# Check for linting errors.
ruff check
```


## Logging

You can set the `PYGFX_LOG_LEVEL` environment variable to get more
detailed log messages. Can be an int or any of the standard level names.


## Attributes

We distinguish four kinds of attributes:

* Public attributes for the user: should in most cases be ``@property``'s.
* Private attributes: prefixed with "_" as usual.
* Attributes used by other parts of Pygfx but not intended for the user: prefixed with "_gfx_".
* Attributes to store WgpuRenderer-specific data on a WorldObject or Material (the objects themselves are unaware): prefixed with "_wgpu_".
