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@blender.org
List details, subscription details or unsubscribe:
https://lists.blender.org/mailman/listinfo/bf-committers
