[Bf-committers] Add-ons Policy Clarification/Discussion

[Ryan Inch]

Hey Thomas et al., I would like to discuss the new add-on policies with 
you in regard to their practical application and the needs of add-on 
developers.

A. I use a custom url for the report a bug button in Blender that points 
to BlenderArtists.  I do this for two reasons:
     a. to point people to my feedback thread on BlenderArtists.
     b. I use a much broader definition of a bug than the C/C++ side of 
Blender does, so to prevent conflicts with the triaging team I point 
users to the BlenderArtists thread to report bugs.

Originally, I kept the default behavior of linking to the tracker, but 
after discussions with Brendan Murphy we decided on the current setup as 
a good enough solution at the time.  However, with the new policies in 
place it sounds like this will no longer be adequate. So, In an effort 
to accommodate both my development needs and the new policy, I would 
like to propose three things:

     1. An additional triage policy that states that reports relating to 
add-ons be left to the add-on maintainers to handle, even if they do not 
keep to Blender's definition of a bug.  (this is partially stated in 
https://wiki.blender.org/wiki/Process/Addons, but add-ons aren't 
mentioned at all in the Triaging Playbook)

     2. That a "User Feedback" button be added next to the "Report a 
Bug" button in the add-on's preferences.
         2a. That an exception to the blender.org domain requirement be 
added for user feedback to preserve add-ons' current user feedback setups.
         2b. If 2a isn't possible, I think the next logical place would 
be to move feedback threads to the User Feedback section of devtalk, but 
since you don't want to take feature requests in devtalk and have talked 
about removing the entire section, this seems rather pointless.

     3. That external "Report a Bug" links are allowed to remain until 
#1 & #2 are in place.

B. I accept design discussions in my add-on's task and use it as a 
central place to keep track of the development of my add-on, so it is 
ever growing.  While this perfectly suits my development and has 
benefits from a Git/Phabricator point of view, I have seen from 
discussions in chat that this is not something that is being 
encouraged.  Since an add-on is pretty much self-contained and there are 
benefits to maintaining a main task for it, I propose that main add-on 
tasks be explicitly allowed in a written policy and encouraged.

C. One of the new policies is this: "Base line is that each add-on that 
gets bundled, is meant to function at the same quality level as other 
Blender features. What we require from C/C++ we also require from Python 
scripts, not only technically, but also following Free Software 
principles." which would seem to suggest that add-ons will now require 
review for almost every commit, but Blender does not currently have the 
resources to provide these reviews, plus I haven't seen any evidence 
that community add-ons are followed closely enough for most developers 
to give a meaningful review outside of basic syntax and style.  So can 
you provide clarification as to what exactly is meant by this policy?

D. Would it be possible for bundled add-on authors to be notified when 
things that will affect their add-ons are discussed, such as the recent 
SPDX license or MVert struct changes, so that they aren't caught off 
guard and may have a voice in the discussion if desired? I'm not asking 
for a personal email to be sent to every author, but adding the add-ons 
(Community) tag to relevant Diffs is real easy and should do the job.

E. Can add-ons have bug fixes included in LTS release updates?  If they 
are allowed, what types of fixes would be accepted (since add-ons are 
mostly self-contained I would hope that the type of fixes allowed into 
the LTS update would be left to the discretion of the author/maintainer, 
but if this isn't the case, then what would be accepted)?  And can 
add-ons please be noted in the relevant policy documents?


Thanks.
Ryan Inch (Imaginer)