An old blog post says:
WebExtension manifests now support a “creator” property, which is displayed in the Add-on Manager, to indicate the author of the add-on.
Yet, I can find no documentation on the MDN WebExtensions/manifest.json page.
How do we store, modify, and retrieve lists of Creator, Developer(s) and/or Contributor(s)? This was previously easily and explicitly possible in install.rdf and package.json files, but seems to have disappeared in manifest.json.
If these or similar properties do in fact exist, please update the documentation to include them.
If these or similar properties were removed, please update the documentation to make us aware, and also include a summary of the rationale, with a link to the public discussion (bug report, blog, discourse, etc) where such a decision was made, so that we understand what happened and why.
This is a sloppy and lazy practice I have been critical of in the past: using blog posts as “documentation”, rather than properly writing documentation, with the excuse that they don’t want to waste time doing the “same thing” twice. Blog posts are fine if people are into that, but it doesn’t excuse them from neglecting to also update the documentation. Boohoo, it’s a few minutes extra work for the blogger. But nobody at that time has access to this information, and it is shirking a social responsibility to collect that important information into a central point of documentation, rather than relying upon the random chance that a search engine algorithm will display a blog as a result to a query, creating a waste of minutes or hours times the hundreds or thousands of others looking for that info in the documentation.
If division of labor would be helpful, then a process ought to be developed to strengthen the coordination between those predisposed to write blogumentation, and those motivated to maintain formal documentation, such that a quick ping can be generated from the blogger to a pool of doccers who can then pick up the task of digging deeper and update documentation in a timely manner, not weeks, months, or years later, when the software has gone into legacy mode of it’s life-cycle.
Undocumented features are an insult both to those who invested time and energy to implement those features, and everyone else interested in making use of those features. It’s a responsibility and a commitment to uphold a social contract: if the code was important enough to write, it’s important enough to document. No tolerance for laziness, or absence of processes of mitigation. If a process is needed, talk about it and set it up. Good documentation dramatically cuts down the time I spend ranting on discourse. 
That can only be good for everyone.
I am still self-educating, trying to catch up. Perhaps one day I will feel confident enough to take on the role of contributor and actually help out. Until then, I do appreciate the efforts of everyone who contributes and helps keep this browser alive.