What To Work On

GitHub issue labels will let you know what needs help and help you find a project that fits your time budget. Thank you for your help!

  • Estimated Time to Complete

    • XS: Extra Short

      • Find and replace, fix a spelling mistake, make a change that shouldn’t break anything.

    • S: Short

      • Changes that are pretty much localized to one package

    • M: Medium

      • Changes in one package that require changes in other packages

    • L: Long

      • Changes to core architecture or functionality, API breaking changes

    • XL: Extra Long

      • Re-write the codebase(s) in another language

  • Priority

    • p4

      • Nice To Have

    • p3

      • Average Priority

    • p2

      • Medium Priority

    • p1

      • High Priority

    • p0

      • Critical Priority

Who’s Working On What

We all overcommit sometimes, here are the rules for how you can tell if you should work on something, if someone else is already working on it, or if someones work has been abandoned (they might not have time to tell us that they don’t have time to work on it anymore).

  • Don’t worry about asking if you can work on something.

  • If you have started work on something but do not yet have a pull request

    • Comment saying you have started

    • If you don’t open a draft/WIP pull request within 7 days, we will take that to mean you’re not working on it anymore.

  • If you see an open a draft/WIP pull request that hasn’t had any activity on it for more than 21 days. The community should considered it abandoned.

    • If you are still working on it, comment on it saying so. It’s okay to be in progress for a while, just make sure you let others know that you intend to complete it.

  • If you see an abandoned pull request, you can work on the issue it is partaining to.

    • You must comment on the pull request to let others know that you intend to pick up the work.

    • You should consider picking up where the person left off by using the work they’ve posted.

      • Add a Co-authored-by tag to any of their commits that you change, and leave them as the author for any commits you don’t change.

Contacting the Community

You can get in touch with the DFFML community via the following channels.

Communication Style

Logs, screenshots, the command you were running, and any files involved make it easier for other developers to replicate whatever happened so they can help you fix the problem.

Even better than a screenshot is an asciicast. It lets you create a recording of your terminal that can be shared via a asciinema.org link or sent privately as a JSON file.

Creating an issue and uploading any files or screenshots is always encouraged.