Define relation between / and roles of elements in the Add-on ecosystem

[designakt]

We work on many parts of the Add-on ecosystem currently, and are planing to re-define bigger parts of it. (like AMO) To understand what functions each part of the system should fulfill it might help to draw a complete picture of a system we envision. (And to compare it what we currently have, to see where and how we can have the biggest impact.)

• identify all elements of the system
  • identify types of users & developers
  • identify stakeholders
  • identify related systems
  • identify related functions
• map add-on life-cycle
• map user journeys
• map user engagement
• map ecosystem

This exploration of the system started when I outlined the life-cycle of an add-on to understand how different projects we already worked on relate to each other and how to priorities those.

Since then many more dimensions of that system opened up in different projects and that picture grew. This will be an attempt to show that system from different angles to help understand relationships and roles in the system.

https://www.lucidchart.com/documents/view/1a0c645e-4475-46e8-9aed-98828f7b7dda

┆Issue is synchronized with this Jira Task

[designakt]

view on lucidchart

I think I have a model that covers all elements relevant to provide add-ons. (It is somewhat complex so far, but helps me tell stories how different aspects relate.)

@brampitoyo Especially in the developer area I struggle to understand what the optimum should be. I looked at your simplified developer journeys and tried to take what I can from there.
This should not be a model of the current state, but of an ideal future, but is currently somewhere in between. (Modeling the current system could be useful too. Like you did when mapping all information sources for devs.)

Questions I have:

• Should the Developer Hub combine all add-on tasks for Devs, like Documentation and Communication? Or are those best kept separate?
• Do I miss any steps in the development of an extension / theme?
• Do I miss any connections?
• How different are extension and theme developer?
• Are theme developer typical developers?
• What did I miss?
• Am I wrong somewhere? (We probably need to talk through it before you can tell me that. Happy to do so in our meeting on Wednesday.)

Any feedback welcome. I am sure this is not complete yet.

[brampitoyo]

This should not be a model of the current state, but of an ideal future, but is currently somewhere in between.

I noticed a couple of gaps we can streamline (this is an ideal state, not present day):

• There should be a process in which a developer takes a series of feedback from their userbase (usually, these feedbacks are found on the comment section, but they could also run their own email or forums) and then decided to fix or update their add-on. Updated add-ons get submitted to AMO, of course.
• I think that there are different sets of items that constitutes News, like Hacks Blog and Add-ons blog. I think that this is a part of Communication, but this communication comes from us. Then, community members react to that by reporting bugs, problems, suggestion, etc.

Should the Developer Hub combine all add-on tasks for Devs, like Documentation and Communication? Or are those best kept separate?

Ideally, I’d like more integration: one place to get all your resources. While the Developer Hub isn’t equipped to perform all documentation or communication functions, one thing we can do is syndicate them or at least link to them.

At the end of the day, we should be able to answer this question: “What are the places developers can go to learn and build add-ons?”, and the list of those places should be as short as possible.

Do I miss any steps in the development of an extension / theme?
How different are extension and theme developer?
Are theme developer typical developers?

Themes are largely built using a wizard, so I suspect that the learning process will be minimal. Seen this way, theme developers may not go through a lot of documentation, and since we always plan on supporting themes, news is irrelevant to them.

Complete themes are somewhat different. The process that they go through are a lot more similar to add-ons.

Do I miss any connections?

There are two ways to test add-ons:

1. Test it on your own machine temporarily
2. Test it on another machine for a longer period of time

Item 1 is already covered by your diagram. In fact, it’s easy enough to do if you use the “Install Add-on From File…” option. The problem is, your add-on may work on your own computer running Nightly for one session, but this tells you nothing about the real world: how will it run on your user’s machine that’s running Release, after it’s been installed for a while?

Currently, you can do this with a workaround: submit it to AMO as unlisted, download the file, distribute the result. But you can’t just say “Hey, I just updated my files a minute ago. Here’s the add-on. Have everybody on the QA team install it and check it out.” In the future, I believe we are using Unbranded builds to solve this problem. So this should be a part of your diagram, too.