2025-04-24 Extensions Platform

Meetings
1

Attendees:

  • Anna Sirota
  • Dalai Felinto
  • Francesco Siddi
  • Márton Lente
  • Nika Kutsniashvili
  • Oleg Komarov
  • Pablo Vazquez

Meeting to align the extensions platform development roadmap for later this year.

See also: latest extensions design sesion meeting notes.

Potential features/development work:

  • “Create extension” workflow [Dalai].
    • Needs design.
    • Options for converting an existing add-on.
    • Ways to help creating a one from scratch.
  • Comment/change status workflow [Dalai].
    • Limit the amount of options available and turn them into buttons. Mockup
    • Display correct tag for “Awaiting Review” extensions on top of the page [Nika].
  • Branding (making Blender an opt-in feature?) [Dalai].
  • 1/3 of add-ons don’t request second review after initial one. How can we help? [Nika]
    • Most developers don’t have enough knowledge to address review points. Virtually no documentation exists to help them.
    • Add docs page to website?
  • Abuse reports: Feedback isn’t clear and communicated [Nika].
  • Make support/bugtracker URL mandatory [Nika].
  • User requested feature: Favorites/groups of extensions [Nika].
  • Moderation of subsequent uploads: decide if/how we need it [Oleg].
  • Known UX complaints #210 - Broken/obscure navigation - extensions-website - Blender Projects [Oleg]
  • Support for de-listing extensions by their authors, #294 [Oleg]

Low hanging fruits:

  • On extension save, redirect to “review” page instead of versions list [Dalai].
  • Make approval queue easier to enter for users [Nika].
  • Make it possible for users to remove their extension ratings.
  • Rewording “Max. Blender version” to first breaking version? [Márton]
  • …

Meeting notes:

  • Publishing a new version for a published extension (based on an example with a mistake in website manifest field):
    • shouldn’t happen immediately with a file upload
    • a parsed manifest should be displayed for verification, and there should be two options to proceed: add release notes and publish OR cancel the upload. If upload is cancelled, the version number is not reserved, so it’s possible to re-upload a corrected file with the same version number.
  • Deleting extensions and versions:
    • There are valid reasons for both extensions and versions to be deleted by their authors. E.g. a version containing GPL-incompatible code may be mistakenly published, or an author may change their mind about having an extension associated with their name, or for some other personal reason.
    • When an extension or a version gets unpublished, its id (extension_id or version number) stays reserved (see also Yanking - PyPI Docs).
    • On the Blender side it should be clear whan a previously installed extension becomes unpublished. Think of appropriate presentation and terminology, some options: “orphan”, “unmaintained”, “remote broken” status?
  • Extension icons will be made optional. Need to design a placeholder icon.
  • For extension without a preview (those are only migrated legacy add-ons), we should hide the “no preview” placeholder to save space on the page.
  • Addressing “awaiting review” status confusion:
    • We will forbid review status transitions from “Approved” status to “Awaiting review” or “Awaiting changes”
    • When changes are requested, the extension page will show “Awaiting changes” instead of “Awaiting review”, communicating the status to authors in a clear way everywhere
  • Review of subsequent version uploads:
    • Authors won’t be exposed to any workflow changes. Once an extension is “Approved”, no actions on the author’s side will be required.
    • We will look into making the post-publish moderation of subsequent uploads more realistic, possibly integrating some diff-viewer with the review tool/script [?].
  • Many authors don’t come back after receiving their first review comment from moderators.
    • This creates workload for moderators without positive outcomes for the authors and the platform.
    • The hypothesis is that we need to provide more guidance to authors who don’t have sufficient developer background, because often in those cases moderators have to take on an educator’s role.
    • The proposed solution is to publish “dev docs” on user manual [?] or on the extensions website, so it’s easy to link to those during reviews. Example of docs page.
  • Abuse reports are flooded with bug reports that should be directed to extension authors.
    • Apparently the “support” link is not visible enough, and the abuse report form is too open.
    • The proposed solution is to make one prominent entry point for all reports, and make the dispatching of various report types more obvious. One option is to update the current abuse report page:
      • add a prominent “support url” link or when there’s no support url state it clearly (also on the extension page, smth like “no support, use at your own discretion”)
      • add a link to report Blender version incompatibility (we already have a small flag icon in the sidebar that does that); we may also consider directing users to the support url for reporting incompatibility; we expect that with 5.0 release a lot of extensions may become incompatible and we should make sure that the platform is presenting correct ranges
      • remove “other” option from categories in abuse report form
      • that form also doesn’t need a “version” field
  • Abuse report handling:
    • it’s not clear what “resolve” does, e.g. a review is removed, but what happens for an extension? it should be communicated before the button is clicked
    • users need to know when their abuse report is resolved or dismissed
    • consider supporting a conversation thread in abuse report, example: copyright claims when we want to ask for follow ups
  • Mandatory support link (bug tracker):
    • Maybe too much, would discourage creators who want to share without long term maintenance.
    • In that case, users should be warned that extension doesn’t provide support and they should use it in production at their own risk, because extension might break with newer Blender versions and make switching difficult.
    • Decision: When creator doesn’t provide support URL display “Support Not Provided” (final wording to be decided) on extensions page.
  • Notification filters by type, extend subscription options (some moderators deal only with abuse reports and with upload reviews).
  • Support favorite extensions and collections:
    • make them shareable (useful in teaching context)
    • subscribe to new version notifications
  • Rating authors should be able to delete the ratings they created.
  • Templates for creating an extension from Blender: requires a definition of steps, and a clear design.
  • Branding of self-hosted repos: make it easier to customize logo/title/links (e.g. sign-in)/footer/header. The reason is to remove obstacles for people to do the right thing.
  • #211 - Move about page images to static storage - extensions-website - Blender Projects Let’s add the images somewhere, e.g. in the repo. The only caveat is that the images may need to be updated with new Blender versions.
2 Likes