I’m a DevOps engineer with git experience and in supporting software teams. How can I help in the development of Jerboa for Lemmy and for the fediverse in general? Should I learn the language and literally code, or can I groom the backlog, or so user testing?

  • @FleaCatcher
    link
    62 years ago

    with experience with git

    Hmmmmmmmmmmm

    • @PmmeyourtoasterOP
      link
      72 years ago

      Not sure what the implication is here, but have a hope that everyone maintain a growth mindset. I provided one skillset I have here, but have many others I didn’t list and am willing to learn.

        • @PmmeyourtoasterOP
          link
          22 years ago

          Good point. I absolutely see now where that could be a red flag. I should have said experience in git, or experience with version control systems, etc. I updated my post. Thanks for the context.

      • @FearTheCron
        link
        12 years ago

        Perhaps grammar? You have a couple of “with” in close proximity to one another. Such mistakes just let us know you are a real developer though :-)

  • Vamp
    link
    52 years ago

    Contact the app developer for Jerboa, they should have their own community with the same name as the app. As for the instance itself I’m not sure as they don’t have anything liked on the instance’s sidebar itself. Might be worth checking the main communities for this instance

  • @[email protected]
    link
    fedilink
    English
    32 years ago

    My recommendation is get an instance going, run it in that latest release candidate, if not the bleeding edge / build from source. Find and report issues. Since you are in DevOps, help expand the operational side / documentation.

    I had a PR yesterday to fix nginx config, which you could probably have done as well? Help other people with their instances, document solutions. There are lots of places where you can apply your set of skills, rather than trying to learn Rust and just write code

  • @FearTheCron
    link
    32 years ago

    The easiest way to get started is to just find a self contained issue on the issue tracker and fix it.
    Most major open source projects will have documents on how to contribute but the workflow is typically something like:

    1. Fork the repository and make a branch
    2. Fix the issue
    3. Make a pull request back to the original repository.

    When you are getting started, it helps to make small changes that the maintainers can easily review. For example, this issue looks like something that may be fixable without too many changes. Also, evaluating the patch is pretty easy since the bug is reproducible.