OSE Develoment Task Assistance

From Open Source Ecology
Jump to: navigation, search

Introduction

The key to rapid development is modular design with parallel development. When projects can be broken down into small tasks, many people can work on them in parallel. The point is that modular design and parallel development depend fundamentally on the ability to coordinate development tasks. Thus, in augmented development practice, it crucial to learn the skills of collaboration - to gain a fluency in this skill - which we call Collaborative Literacy.

The critical part here is to share a language of collaborative literacy, which enables everyone to understand the status of what has been done and what needs to be done:

  1. How to break down a project into individual tasks. This means how machine systems, machines, modules, and parts can be broken down
  2. When have contributions been made? This is done with timestamps, such as edit date on the wiki.
  3. Which tasks are done and which need doing. An automated platform that populates a scrum board with tasks should be produced. If a person is working on a task (as noted by an edit on a given development template), that person's name should populate the task automatically.
  4. What tools and resources are available for doing tasks
  5. What is the desirable order for task execution
  6. When to stop, continue, or iterate
  7. What is the 'definition of done,' ie, what constitutes completion
  8. Who is working on what tasks within the project
  9. Who are other groups doing related work?
  10. How are results communicated within and outside of the group?
  11. What skill sets are required to develop tasks?
  12. What skill sets/members does the project already have?
  13. What is the roadmap for a given project? What are the milestones for the project?
  14. Who is the project manager and product owner, and who is the team?
  15. What is the level of activity of the team? Github for example does this by showing an activity graph.
  16. What is the burndown of a project? This is already accessible at Burndown and linked automatically to the level of completion of a Development Template.

If the above can be understood in detail, it can be automated, such that artificial intelligence can guide the process, and the process can possibly be tracked on a distributed ledger.

Collaboration between open source projects works well when two projects are working in the same area - and tasks can be broken up for different people to work on them. However, many open source developers are cultural creatives absorbed in their work to the point that working with others is difficult for various reasons.

Solo Warriors

We encourage collaborators not to be solo warriors. While it takes effort to coordinate and work together, the rewards are ample. The ability to cooperate is a learned skill - and a valuable one. It is what allows for results much greater than oneself.

The key to open collaboration is the recognition of the benefits, and the willingness to learn the skills of effective collaboration. I've seen many people express that they could get more done by themselves, but that is a solo warrior mindset that should be overcome as a general practice. Such a mindset may be influenced by egoism and insecurity - both of which are values that do not help an open, collaborative process.

Addressing the Loss of Focus when Collaborating

A typical critique of collaboration is that one loses focus and gets less done.

To address this - collaboration does not mean that one has to work in the presence of another person at the same time. Collaboration can be asynchronous and remote. For which reason the more suitable term may be coordination. But the thing that must happen is that multiple parties must follow shared procedures and protocols - and an online infrastructure must be available to execute the procedures and protocols.

In fact, the most effective collaboration infrastructure may be one that allows for the most alone-focus time - unless a group is so skilled that group activity promotes group flow experience.

The point to keep in mind that focus and collaboration are not mutually exclusive.

Collaboration Protocol

Are you working on an open source hardware development project? OSE can help you in this by offering its basic protocol for collaboration. This protocol simply involves starting a Work Log so others can see your work, basic familiarity with FreeCAD 101, usage of the Development Template with its Burndown, and mass collaboration spawning using the incentive-prize HeroX crowd development platform to build a team and reward contributors. Furthermore, a Product Manual Template is available for publishing instructionals on different technologies. If anyone is working on a a project by themselves, we request:

  1. They port their design to FreeCAD
  2. Spend 5 hours posting a Design Challenge on HeroX - by documenting their work and the challenge consisting of people contributing improvements within FreeCAD.
  3. Hosting a Design Sprint with 100 people to develop the next design and to publish the design in a Product Manual.
  4. Adding the product to a collaborative production website (only minor tools required for assembly), and anyone benefitting from the sales and delivery of the product.

For successful Design Sprints, we need a complete Development Template protocol set to be defined, along with a tutorial on all the steps - such that 100 people minimum can work effectivele in parallel via a 1 day per month commitment.