CoderGlue: Let’s Code Together 😉 This topic was inspired by FedeProxy project, and my interactions on their forum. There’s a wink in the title, because “CoderGlue” name and icon design is just a proposal I made, as alternative more descriptive project name. Nothing more than that. Culture and process I really like how the team is setting up the FedeProxy project organisation. A thorough approach, deep thought, and proper preparation. So too on diversity: @anon20068248: Diversity: F...

This SocialHub topic was inspired by Forgefriends (then called FedeProxy) and constitutes a wild brainstorm for envisioning what could be an entirely new paradigm to softwrare development: United Software Development.

Exploration of the idea involves looking from a non-technical perspective at all the possible ways in which Decentralization and fediverse standards (ActivityStreams, ActivityPub, Linked Data) can be leveraged to shape this paradigm.

Preliminary definition of United Sotware Development is “Free, libre software development, processes and culture united,. Sustainable, open and accessible to anyone.”, but I’m sure that can be further improved.

@dachary@lemmy.ml offers a very enticing look into what “Federated Development” might entail. I highly encourage people to read the SocialHub thread, and am very curious about your musings and thoughts.

  • @csdummi
    3•2 years ago

    My post is incomplete though: I’ve defined problem that the united software development paradigm should set out to solve, but I didn’t provide much information as to how that problem might be solved.

    For that I suggest a new definition of the free software development process:

    1. An idea is had and published.
    2. The idea is made concrete.
    3. A group of developers finds themselves to work on the idea.
    4. The group writes the code.
    5. The group makes a release.
    6. The group’s software gains adoption
    7. The community of users and the developer group grows.

    At no point during this new process does the success of the project depend on an individual. Indeed each step of this process could theoretically be done by a different person or persons. Thus requiring a whole new definition of what a maintainer is, how they become one and forge software has to change accordingly.

    And there should be software to support the first three steps of this process especially, software where you could publish ideas (1), make them concrete (2) and find developers to work on a project together (3). Federating this software and embedding it in Gitea or another federated forge would probably be the best approach.

    Since Big tech cannot use this process really, since it includes giving away your ideas and not just your code to the commons.

    • smallcirclesOPM
      1•2 years ago

      Wholly on board again for this idea. Holistically addressing the whole process, including ideation and forming of the community that starts to tackle a particular idea. It need not even come off the ground into a streamlined project altogether. If a groups starts working on an idea, then leaves it by lack of interest or something, they will still have forwarded it and it is just waiting for the next person or group to add something to it. The whole idea of “dead projects” because the maintainer throws the towel in the ring can become smaller.

      • @csdummi
        2•2 years ago

        Maybe a little mental prototyping is in order:

        A project based on the fediverse may be created, that:

        1. Allows any user to publish an “Idea” Object containing anything from a small word impulse to an entire whitepaper.
        2. That “Idea” Object can be extended to become a “Concrete” Object, containing more technical details.
        3. The “Concrete” Object is proposed to developers.
        4. Developers join a project. Meaning they want to work on the project. Creating a “Group” Object.
        5. Developers are given a public discussion room for internal discussion.
        6. Developers create a repository on a forge and select a maintainer from amongst their members. (Maybe by voting?)
        7. Development begins.

        (Whenever I say Object, I mean an ActivityPub object)

        Developers should be able to join and leave a project at any time. And if they are a maintainer, the group should just be able to chose another developer from amongst their members.

        (This can be risky, if a project is entirely abandoned and a malicious entity gains control of the project, at which point a “fork” of the project should be created - nobody with a link to the abandoned project should receive releases from that anymore.)

        • smallcirclesOPM
          1•2 years ago

          It may be easier to split this into two domains that can evolve separately: Ideation and Project Management.

          Just some additional points to the ones you mentioned (obviously it should start minimal, but just brainstorming right now). Going further it may be an idea to diagram these domains, as that’s a good way to slash details and focus on essential process.

          Ideation

          • Anyone can create an Idea (e.g. in markdown format, and maybe deriving from an Idea template).
          • An Idea may have a Category and Tags. E.g. category “Podcasting”.
          • Any fedizen can follow a Category and find new Ideas as toots in their timeline, containing Tags as hashtags.
          • Any fedizen can comment / discuss the Idea, their comments become replies to the original toot.
          • Might be possible to collectively edit/refine (parts of) the Idea text (might need revision checking, rollback by owner).
          • People can navigate the UI, find all kinds of ideas based on the metrics collected for it.
          • People state their interest to participate in a Project based on the idea, and what they can do for the project.
          • Any Person can create a Project based on an Idea (an idea can have multiple projects).

          When a project is created the Ideation still continues. The ideation process goes in parallel.

          PS. Something along similar lines is the open-source-ideas GH repo.

          Project Management

          • Project is the top-level object. It has association with the Idea. It has a Community (a group).
          • The project creator becomes the Organizer and is responsible for bootstrapping the Community.
          • People may Join or be Invited into the Community.
          • The Community may have a Governance Policy (that sets CoC, ToS, voting scheme, doc templates, etc.).
          • Community members may indicate their preferred Roles (e.g. UX Designer, Tester, Developer), maybe Availability too.
          • For the more formal roles (those that come with privileges) there may be Votes.
          • Ideally there’s more than one person in an authoritative role (to tackle risk of maintainer abandoning).
          • Maybe there could be a ‘credentials vault’ and a way to upvote trusted persons to a Role where they can manage it.

          PS. I’ve witnessed some nasty examples of a maintainer disappearing and not even willing to update the README to point to the newly active fork where stuff continues.

          PS2. There may also be a 3-domain split, where you have Community Governance and Project Management separately.

          Related ideas on forgefriends: POC: Provisioning Open Communities and ASK: Aggregating Software Knowledge

          • @csdummi
            2•2 years ago

            Those are great ideas. I’ll try to minimize these into minimum viable product requirements based on the three domain split:

            MVP

            Ideation

            A service which allows the sharing, discussion and concretize ideas.

            It should achieve these minimum features:

            • To create ideas as ActivityPub Objects containing text, tags, and a reference to an Idea it’s based on (if any).
            • To discuss Idea Objects in the Fediverse.
            • To gather the discussion in an easy to view UI.
            • The change of Idea Objects should be possible for the author of the Idea.
            • Any user should be able to create a new Idea based on an existing Idea Object.
            • To generate a feed for users to find new Idea Objects.

            Community Governance

            A service closely working together with the Ideation and project management service.

            It should achieve these minimum features:

            • The creation of a developer community Object (group) based on an Idea.
            • Users to join and leave a community.
            • Users to assign themselves roles, describing their abilities and resources they can provide to the project.
            • Users to vote for a maintainer of the project and communicate this with the project management service.
            • Users to discuss the project on the Fediverse.

            Project Managment

            A forge that hosts the repositories of a project and allows for the Community to change the access levels of developers (Maintainers, Contributors, etc.).

            It should achieve these minimum features:

            • To create repositories for a community.
            • The features of forge (issue trackers, contributions, etc.)
            • To change access levels based on the Community Governance.

            I decided for this three division, because Project Management can be seen as a Forge with some additional features (maybe implemented with just a plugin or bot) and the focus of development should lie on Community Governance and Ideation, the new and unique services.

            I only include those requirements here, which I think can be reasonably implemented in a first release and nothing more.

            • smallcirclesOPM
              1•2 years ago

              Wonderful! Just going to add some remarks / thoughts… we might call this the “Social Coding MVP” and when spinning up an app, it is a “social coding platform”.

              Ideation --> Idea Management

              • “Idea Management” appears to be a more common domain name.
              • Federation between social coding instances:
                • Consider a solarpunk.community and a vidartists.social instance.
                • Ideas should be spread far and wide, ideally federate between instances.
                • A solarpunk “low-energy video editing” idea is interesting to vidartists, a “solar panel upcycle” idea is not.
                • There may be need for a Topic as a separate concept. It might be an as:Group on the wire.
                • Instances receive all Topics from across the fedi, then admin subscribes to interesting ones.
                • Only Ideas matching Subscribed Topics are tracked / stored in a particular instance.
              • Federation across the broader fediverse:
                • From any federated app, e.g. Mastodon, a fedizen can Follow a Topic and then get all topical Ideas in their timeline.
                • This works somewhat similar to Gup.pe groups app.
                • If I follow “Video Editing” on vidartists, I will also get Ideas in that topic that were created on solarpunk.
                • I don’t know if de-doubling is handled if I subscribe to the topic on multiple instances.
              • Licensing of ideas
                • Different instances may have different ideas on how Ideas and the comments to them are licensed.
                • The license that applies is determined by the instance that the Idea / Comment was created on.
                • If one replies from e.g. Mastodon, then the license of Idea is used. It should be indicated in the Topic Profile.
              • We can create a diagram and derive our own vocabulary extension for our domain. Interesting prior work:

              Community Governance

              • I’d split this into two separate parts / concepts: Community + Policies
              • Both of these concepts have way broader applicability than our use case, and we can standardize on their definition.

              For a minimal Community vocabulary extension that facilitates having arbitrary ‘Roles’ I suggested modeling them as follows:

              Community vocabulary diagram

              Project Management

              • There is the DOAP Ontology to describe projects (also posted to forgefriends).
              • I guess that the Project Management features here should be mostly informational.
                • Referencing repo’s, tools that may exist anywhere. Insight into any relevant project info.
                • Ensuring that privileges are properly guarded and to the interest of the community as a whole.
              • @csdummi
                2•2 years ago

                I think this discussion is outgrowing it’s frame. (Something we need to strictly avoid in a federated Idea, Community and Project Hub.)

                I propose moving this into a Repository or Organization on a forge.