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?

    • Pmmeyourtoaster@lemmy.worldOP
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      1 year 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.

  • Rulasmur@mhl.onl
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year 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

  • Vamp@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    1 year 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

  • FearTheCron@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    1 year 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.