Workflow for Social Coding Movement

Move your thoughts 💭 Advocacy
#1

In this topic I would like to discuss a workflow for Social Coding that drives the crowdsourcing of content and enables the Movement to constitute a Community of Action.

Note: This top-level post will be updated to contain an up-to-date summary of procedures for building the movement.

Using this forum

When creating a new topic in this forum, consider the Activity Track (see below) the topic fits to best, and select a category or sub-category accordingly. Add a tag to the topic e.g #idea when posting an idea in the #ideation-hub:ideas sub-category. And #challenge when posting in the #documentation:challenges sub-category.

If you find the need to e.g. tag a topic with both #idea and #challenge tags, then consider splitting it up in two different posts and cross-reference them to each other.

Activity tracks

There are four parallel activity tracks to the crowdsourced activities in Social Coding Movement:

  1. FSDL: Elaborate the Free Software Development Lifecycle, focused on project health, sustainability and success.
  2. Foundations: Elaborate Software and Protocol Ecosystems, focused on substrate formation, evolution and adoption.
  3. Documentation: Process of Identify Challenge → Outline Best-practice Pattern → Update Practitioners Guide.
  4. Ecosystem: Help Solve Challenges and Implement Ideas by the Movement’s affiliate communities and projects.

1. Free Software Development Lifecycle

Social Coding is participatory free software development that is inclusive to all people and focused on addressing real human needs. The main focus of our movement is on free software projects i.e. FOSS development. The lifecycle of such projects goes from the earliest seed of an idea, through the entire process of implementation, deployment, maintenance, up to the very end where the project ceases to exist.

More information on the FSDL activity track (click to expand)

Such lifecycle guidance existed before, in the form of the Rational Unified Process (RUP) developed in 1987 by Rational Software Corporation:

Overview of Rational Unified Process, source Wikipedia

The last years of SCRUM / Agile / Lean Startup trends have given a different focus on software development. One where there was less emphasis on the entire development lifecycle. Nowadays negative effects of this focus become more apparent. Agile alone isn’t enough. RUP is at heart an agile process. It’s flaws are likely that it was too prescriptive and tied to formal UML modeling processes.

FSDL will have a similar structure and scope as RUP, but it will be more flexible and tailored for the dynamics that exist in the free software community. FSDL will be a navigable Library of Design Patterns where you can pick and choose best-practices for particular challenges you face in free software project.

Like RUP you will be able to drill-down to relevant content in intuitive ways, and patterns may be presented in a map (e.g. like here). At the same time, as part of the Ecosystem Track of social coding movement, tools and other solutions become available to support the library patterns.

2. Foundations and substrate formation

The Foundations activity track focuses on three subject areas, that are also part of the FSDL:

  1. Free software project community building.
  2. Free software project ecosystems.
  3. Technology and open standards adoption.
More information on the Foundations activity track (click to expand)

1. Community engagement. Most FOSS projects want to build a lively community around the project, consisting of core team, contributors, and any other person that is somehow involved with the project. Building active and inclusive communities is very hard. It requires soft skills, governance procedures, and many other aspects, while it provides opportunities to involve people with different skills and backgrounds to the project. Most FOSS projects struggle with community building, or neglect it altogether.

2. Project ecosystems. Some FOSS projects are part of a larger ecosystem of projects and communities, or enable such ecosystem to be built on top of their work. Building a healthy ecosystem that can grow, mature and evolve in a healthy manner comes with unique challenges, that are both technical and social in nature. Getting independent projects and communities to align with each other, foster collaboration and cross-pollination is the focus in this area: Substrate formation at project level.

3. Technology adoption. Even more challenging is substrate formation at the level of a technnology or open standard. There are less direct ties to the adopters of the tecnology or standard. Participants in the ecosystem must be incentivized to participate in evolving the technological landscape and make onboarding for newcomers easier. Doing so creates a win-win situation, but that isn’t always obvious. For instance for the Fediverse we can state that there is a “Tragedy of the Commons at Protocol Level” and Fediverse faces Major challenges as a result of that.

In order to tackle the challenges posed by 2) and 3) there must be a focus on substrate formation i.e. the people and effective processes that can drive ecosystems and technology adoption and that can innovate and evolve them collectively.

3. Crowdsourcing documentation

Documentation exists on the Social Coding website. Given the scope of the FSDL the website will gradually expand and must be crowdsourced. The website has three main content sections:

  1. Challenges: Documents challenges encountered, relates them to the FSDL and to Best Practices that can solve or mitigate them.
  2. Practices: Documents best-practices to solve particular Challenges, and how they are related to the FSDL.
  3. Practitioners Guide: Recipes / guidance for entire processes within the FSDL (referring to multiple Challenges and Practices).
More information on Documentation activity track (click to expand)

The Challenges and Practices will be documented according to a template for consistency. Together they form the Pattern Library. The various patterns cross-reference each other for navigability, and contain pointers to external resources. The Practitioners Guide is more of a free-form format. But all of the pages need to be succinct, easy to parse and understand. Less is more.

Besides the three main content sections there are more pages that will be updated and improved over time.

4. Social Coding ecosystem

The Social Coding Movement is a co-shared umbrella community that many other communities and projects can use as their home.

TODO: Elaborate this activity track. Until then for more information see this HedgeDoc pad.

What do you expect or hope to see in Social Coding Movement?
#2
#3

Doug Belshaw mentioned a great tool to figure out some important things to get the Social Coding Movement, the co-shared community parts, going:

Architecture of Participation

Overview of Architecture for Participation

The term comes from Tim O’Reilly: “I’ve come to use the term “the architecture of participation” to describe the nature of systems that are designed for user contribution”. Doug mentions the following 8 points to give due attention to:

  1. A clear mission — why does this project exist? what is it setting out to achieve?
  2. An invitation to participate — do you have an unambiguous call to action?
  3. Easy onboarding — are there small, simple tasks/activities that new volunteers can begin with?
  4. A modular approach — do volunteers have to commit to helping with everything, or is there a way which they can use their knowledge, skills, and interests to contribute to part of the project?
  5. Strong leadership — do the people in control of the project embody the mission? do they have the respect of volunteers? have they got the capacity to make the project a success?
  6. Ways of working openly and transparently — does the project have secret areas, or is everything out in the open?
  7. Backchannels and watercoolers — are there ‘social’ spaces for members of the project to interact over and above those focused on project aims?
  8. Celebration of milestones — does the project recognise the efforts and input of volunteers?

Here is some more background by Laura Hilliger:

Developed by Doug Belshaw for We Are Open Co-op, licensed CC-BY.

4 Likes
Discuss our Community Participation Guidelines
#4

It feels like there is something missing. I agree with all the points, but they feel like “I want peace in the world, here is how to achieve this: (i) be nice to each other, (ii) communicate”, if you see what I mean.

1 Like
#5