Hi all. Very happy to see Lemmy’s success so far. I’m interested in contributing to Lemmy’s growth.

At this stage, the engineering team should consider bringing some additional public-facing structure, such as:

1. Published roadmap
2. Performance metrics and reporting
3. Community outreach - keeping user base in the loop on roadmap, launches, metrics, growing pains 

Lemmy will continue to grow regardless, however bringing some structure will onboard new users faster and add trust to Lemmy’s image. Trust factor is important - Reddit refugees are evaluating alternatives to Reddit, and are ultimately choosing off relatively little information.

What is the best way to get involved in new initiatives for Lemmy? I have experience with this type of work (engineering manager at a large tech company), focused on building teams, product roadmaps, and continually improving customer experiences through engineering.

  • tyfi@wirebase.orgOP
    link
    fedilink
    English
    arrow-up
    12
    arrow-down
    2
    ·
    1 year ago

    The GitHub repo will be focused on software-level initiatives, whereas I’m talking more about product-level.

    If the team is that small, then they need more people involved in product ownership, which is what I’m interesting in contributing towards (as others are too, I assume)

    • calr0x@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      11
      arrow-down
      3
      ·
      1 year ago

      I think it’s just too early for that level of formality. Basically they’re swamped just actually executing changes versus the type of planning you’re talking about. Maybe you can offer to help them in some way with that?

      • tyfi@wirebase.orgOP
        link
        fedilink
        English
        arrow-up
        10
        arrow-down
        2
        ·
        1 year ago

        The issue with that approach (too busy to build structure), is that it’s a never ending battle. There is never a good time. It’s an easy trap to fall into.

        The best way to be successful with products like this is to invest time early in building out the team. By doing so, you’re multiplying output and limiting tech debt.

        I would even be happy to help with helping build out the team (identifying gaps, key roles, volunteers) as that’s something I’m experienced with.

        • calr0x@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          5
          ·
          1 year ago

          None of this should come across as argumentative or being short. My understanding is it’s just two people so I still think this isn’t a time to have ideas. Shoot them a message on GitHub or whatever community they have set up for feedback and help build the ranks to get them to help they need… ;)

    • Drunemeton@lemmy.world
      link
      fedilink
      English
      arrow-up
      5
      arrow-down
      1
      ·
      1 year ago

      Welcome to the Fediverse. I don’t think what you’re looking for can exist here. (And that’s by design…)

      Lemmy is the software that ties the instances together. GitHub link was already provided.

      Instances are run independently. Each has “product ownership” in just their own instance. There are over 10,0000 instances, and that number grows daily.

      So you’re going to be trying to get 10,000+ cats to sit still for a group photo. Good luck!

      • tyfi@wirebase.orgOP
        link
        fedilink
        English
        arrow-up
        5
        arrow-down
        2
        ·
        1 year ago

        That would be true for metrics/performance reporting, yes. It would make sense to build something that was opt-in for instance owners to submit data.

        Regardless of the mechanism – there will need to be some way to evaluate the performance impacts of changes that are continually being rolled out.

        Thanks :)