What type of user is an Adapt user?

How often do you use the word "users" only to find yourself being called to qualify it: "Do you mean technical users or non-technical users?"

In quick chat we often use "user" as a placeholder. We're trusting that it will be apparent from the context that our user is a network specialist rather than a course author. Honestly, that often works just fine. But there are times when more precision is valuable. When using a refined vocabulary, we perceive our world just a bit differently. That’s my hope, anyway, for sharing some alternate vocabulary for talking about Adapt community members. Categorizing them differently can expose different needs and different ways we can care for the community. 

Refining Vocabulary

I recently read Simon Phipps’ short article entitled “Community Types.” I encourage you to do the same. His concepts are easy to apply to the Adapt community.

Using the vocabulary of Phipps, we can see two broad communities forming around Adapt. The community nearest to the focus of the project, the source code, is the Developer Community. The Developer Community shares access to the code and changes it. The second community is the Deployer Community. Its primary involvement with the code is through running an instance of it and through interacting with the Developer Community. 

Adapt’s developer community is easy to find. Look in the gitter rooms. They’re populated by developers who are sponsored by collaborating companies, by developers whose companies have found a revenue stream in Adapt, by developers who enjoy interacting with folks who are using the same technologies.

But don’t stop there. Look at the repos. Find the names of those submitting PRs. Find the names of those who have been granted merge permissions. These are the developers that are contributing to the code base. The framework and the authoring tool originate from their work. Phipps refers to these folks as the Co-Developer Community. He distinguishes them from another sub-group in the Developer Community: the Extending Co-Developer Community. These developers also contribute code through PRs, but their work is not focused on the framework and the authoring tool. Their names show up more frequently on PRs for components, themes, extensions, and menus. Their work on plug-ins extends the usefulness of the primary code base.

Phipps identifies another community, the Deployer Community, that also spans two sub-groups. This community is focused on what has been produced by the Developer Community. One sub-group, the Deployer Developer, configures and customizes the framework or authoring tool so that it can be used for its intended purpose. These folks know the code base well enough to install it and to integrate it into other systems. The other sub-group of the deployer community is the User—ah, I finally get to use that word. They are the ones who employee the code for its intended purpose. They create courses using the Adapt framework or the authoring tool. 

A quick summary follows of how we can see Phipps’ categories in the Adapt community.

Developer Community:

• Co-Developers are coding the framework and the authoring tool. They are originators.
• Extending Co-Developers are coding plug-ins (components, extensions, menus, themes). They are extenders.

Deployer Community:

• Deployer Developers install the framework or authoring tool and customize the code base for use in a particular environment.
• Users take the work of the installer and put it to productive use.

Of course, people take on different roles. While these four types are a handy distinction, a single person might fulfill each as a job requires. For example, a front-end developer (deployer role) might contribute code to a plug-in (developer activity) that resulted from customization requested by a client.

How does this vocabulary benefit the Adapt open source community?

I’d like to suggest a few ways.

• Adapt is built around two products, the framework and the authoring tool. Rather than categorizing community members based on the tool they use, Phipps' vocabulary draws out similarities based on the member's role, on how each interacts with a given product.
• Needs can be extrapolated for each group. The deployer community has many of the same needs whether members work with the framework or the authoring tool. The same is true of the developer community. When these are addressed, a stronger, more balanced community prevails.
• Documentation needs to differ for each role. Indeed, the appropriate format of documentation may differ.
• Different types or sub-groups need different support that in turn can be supplied by the different communities. It should not be assumed that a co-developer is the best support agent for a user.
• This vocabulary emphasizes relationship to the project code base in a continuity from code originator to end user. This provides a construct for more action by the community than can be found in a member's skill-set, as implied in such terms such as 'technical user' and 'non-technical user.'

What other benefits do you see? Does this vocabulary have a negative impact? What actions does it call for in the Adapt community?