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

[Thomas Dinges]

Hey Ryan,

Thanks for your mail on this topic. Disclaimer: The following is my 
opinion, a formal decision is up to the BF admins and the add-on module 
team. :)

A)

I don't think external links for bug reports are explicitly covered by 
the current key-requirements. They only mention to "offer the full 
documentation on blender.org".

The reason for these requirements are mainly to have everything on 
blender.org, for users to make full use of the add-on without requiring 
to access external sites or download additional extensions. In my 
opinion this doesn't strictly include its development. Some developers 
maintain their add-on Github and just commit a new version to the 
blender repository once in a while.

B)

Phabricator is a development platform and not the proper place for user 
feedback and discussions. Development tasks are already interrupted by 
user questions and off-topic discussions. I rather have the same rule 
for everything (Blender itself and Add-ons) and not encourage people to 
use Phabricator as a discussion platform.

Devtalk is the correct place for this, as long as this call for feedback 
is initiated by the developer. We have feedback threads there already 
(for example for Cycles). So feel free to open a feedback task there.

C)

They don't require review for every commit, but review is always highly 
encouraged. The same rules should apply for both Blender code and 
add-ons, that's the main reason for this point.

D)

API changes and implications for add-ons should always be communicated 
properly. Tagging the add-ons project in related patches is a good idea.

E)

Add-on bugfixes can be included in LTS updates. But it should be fixes 
alone and not new features. Same rules apply here again like for 
general  Blender code.

Best regards,

Thomas

Am 11.03.2022 um 07:42 schrieb Ryan Inch via Bf-committers:
> 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)
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers

-- 
Thomas Dinges  -  thomas at blender.org   -  www.blender.org
Developer Community Coordinator at Blender
Buikslotermeerplein 161 - 1025 ET Amsterdam - The Netherlands