Code Contributions

FastEddy is developed and maintained by a small team with limited funding and resources. While we aren’t able to support a large volume of external contributions, we do value engagement from the community and appreciate when users share ideas, improvements, and expertise.

This page outlines how to work with us in a way that helps set everyone up for success.

Start with a Conversation

If you’re thinking about contributing, we strongly encourage you to start a conversation with us either with an email to fasteddy@ucar.edu or via GitHub Discussions.

  • Introduce yourself

  • Share what you’re interested in working on

  • Ask questions about fit or direction

This helps us understand your goals, provide context, and collaborate early, especially since contributions should be planned to be incorporated during one of our two annual releases and planning is necessary early on to determine what additions will be part of a release for coordination purposes. Exceptions will be considered for small bug fixes for their incorporation outside of a release cycle.

Share Feedback or Ideas

Not all input needs to come through a code contribution. If you have suggestions, ideas, or have encountered issues, we encourage you to share them through our feedback form.

This is a good option if you:

  • Have an idea but are not planning to implement it yourself

  • Want to report an issue or usability challenge

  • Have general suggestions or feedback based on your experience

Share feedback, suggestions, or report issues to the development team.
Feedback form

Scope of Contributions

Not all contributions can be accepted. In general, contributions are more likely to be considered if they:

  • Have been initially discussed and coordinated with the NSF NCAR FastEddy team

  • Address a clear issue or gap

  • Fit within the current direction of the project

  • Maintain or improve portability

  • Are mindful of long-term maintainability

If you’re considering a larger change, it’s especially helpful to talk with us first so we can explore the best path forward together.

Branching Strategy (after coordination with the FastEddy team)

To keep development organized:

  • develop: This is where active development is introduced. Please target this branch for contributions.

  • main_vX.Y (e.g. main_v5.0): These branches represent stable releases and are not updated with new changes.

If a pull request is opened against a release branch, we will ask that it be redirected to develop.

Pull Request Guidelines

When submitting a pull request:

  1. Ensure your PR targets the develop branch

  2. Provide a clear description of:

    • What the change does

    • Why it is needed

    • Any impacts on existing workflows

  3. Include updates to documentation if applicable

  4. Be responsive to feedback and willing to iterate

We’ll do our best to review contributions as time allows. Because of limited capacity, timelines may vary, and in some cases we may not be able to take on or maintain certain changes, but we’ll aim to communicate clearly when that happens.

Working Together

We’re always glad to see people interested in FastEddy. The best outcomes tend to come from early communication, shared understanding, and a willingness to collaborate within the project’s current scope.

Summary

FastEddy is not currently positioned to support open-ended or high-volume external contributions. However, targeted, well-communicated contributions that align with project goals can be valuable. Starting with a quick conversation helps ensure your effort aligns well with the project and increases the chances of a smooth and productive collaboration. Even if something isn’t a fit right now, we still appreciate hearing your ideas.