And for anyone interested in a template:

  • sik0fewl@piefed.caEnglish
    0·
    10 days ago

    What we need is some sort of distributed version control system.

    I’m not quite sure how it will work yet, but it would have the entire codebase and its history mirrored onto every developer’s computer. Instead of requiring a central repository, developers could share their changes directly with each other.

      • Eager Eagle@lemmy.worldEnglish
        1·
        10 days ago

        git itself is really not far from a blockhain. Blockchain is fine, it only has a bad rep because of ponzi schemes that use it to create crypto, but the technology and trustless consensus mechanisms are interesting.

        • mogranja@lemmy.eco.br
          0·
          9 days ago

          I think blockchain also has a bad rep because every chance is mirrored to every copy of the blockchain? Thus wasting a lot of power and bandwidth for most use cases. Unlike git, where you only push what you want, and everyone only pulls what they want.

          • Eager Eagle@lemmy.worldEnglish
            1·
            9 days ago

            The waste of power is often associated to the proof of work consensus, but that’s not a requirement of blockchain. There are other ways to create consensus.

            The bandwidth requirements really depend on what’s being stored, but it’s usually very manageable for a server. And clients not running validation don’t need to store or transfer that much data.

      • sik0fewl@piefed.caEnglish
        1·
        10 days ago

        It was mostly a joke/irony.

        Git is already a “distributed version control system” that does exactly what I’ve described. On the other hand, relying on centralized systems such as GitHub means that the “distributed” nature of it doesn’t make it any more resilient to failure.

    • Eager Eagle@lemmy.worldEnglish
      0·
      10 days ago

      but seriously, we need project management features that are decentralized: issue tracking, kanban, code reviews w/ comments, and ways to extend functionality without relying on a git forge.

      • waldfee@feddit.org
        0·
        10 days ago

        You could create a git branch with an unrelated history to store this type of data; either as plaintext, md or something more sophisticated for dedicated tools. The biggest hurdle would probably be to define and agree on a standardized format

        • azertyfun@sh.itjust.works
          1·
          10 days ago

          The last thing I want is merge conflicts in my issue tracker. The git data model is simply not right for conversational histories.

          ActivityPub is the obvious solution to decentralize public communication. We’re using it right now and AFAIK Forgejo is working to implement it for their issue tracker.

      • sik0fewl@piefed.caEnglish
        0·
        10 days ago

        Would be cool to see those as extensions to Git. Surely they could just be more Git objects?