Libreoffice-qa Digest, Vol 21, Issue 51

Robinson Tryon bishop.robinson at gmail.com
Sat Mar 30 07:55:27 PDT 2013


> From: Joel Madero <jmadero.dev at gmail.com>
> 2) An "official" badge that will be prominently displayed on templates that
> are:
>     a) bundled with LibreOffice
>     b) Meet some other criteria that is to be determined by QA
>
> *the idea is that these badges would say 'guaranteed to be maintained,
> tested & supported against future releases' or some such thing.

Yes. I'm thinking 3 levels here:

1) Guaranteed testing/maintenance/support (our internal QA Team/Devs
will support this code)

2) Some/Extension developer support

3) No support  ("tossed over the wall" -- do what you like with it,
*maybe* ask a question on the Ask site, but don't file bugs)

>> 1. Close as NOTOURBUG + comment to contact extensions author
>>     -Remember some extensions are bundled with LibreOffice
>>     -Here adding ability to have “comments” on extensions would be
>> great so that users could directly get in touch with extension
>> developers
>>     -If comment not available, having an easy “contact author” button
>> would be good
>
>
> IMO best option, with a caveat that bundled/official bugs get left open as
> NEW and developer of extension can mark as FIXED when they fix it. If it's
> not fixed with X time we ping developer directly, they don't respond, they
> lose official badge (I think X time needs to be quite large)

I think we should make a distinction between Official and
Extension-developer-supported bugs. In some cases, an extension
developer (perhaps backed by a company) might be able to offer BETTER
support than even us, but in many cases a single dev won't have the
resources that we do.

>> * Having an “official badge” was discussed, would be a really useful
>> addition to extension site
>
>
> +1, I think we all agree on this so I added it on top to see if we could get
> that. We should ping Marketing for a design.
>>
>>
>> * If author has abandoned their extension, we can either delete the
>> extension if it's broken or make bug report an enhancement if another
>> developer wishes to fix it
>
> Deletion IMO is no good, leaving it up but doing "something" to say
> "currently broken, looking for developer to fix it" would be best.

So in my 3-category system, an extension in this situation would fall
back into the "No support" category and would display the
corresponding badge/icon.

>> 2) We need to communicate our strategy clearly and effectively to
>> other teams in the LibreOffice project (e.g. the volunteers on the Ask
>> site), so that we all provide a complete and consistent message to end
>> users.
>
> This one is more complicated but should be an ideal case. With our project
> spread out so much, without any hierarchy per say, quite difficult to
> "communicate to everyone"

Yeah, I can't call a 'Team meeting' for the Ask site right now (Note
to self: make this happen :-), but it would be nice for me to be able
to put a note on the Ask site FAQ that says "Explain to users that
different extensions/templates have different levels of support. When
in doubt, ask the QA Team for clarification."

>> A) We provide a strict structure for the Extensions/Templates sites
>> that integrates extension developers into our process.
>
> This may discourage developers from doing extensions - the low barrier to
> entry is a positive IMO and should remain as such. This being said we should
> encourage developers to "apply for official status" which WOULD have strict
> structure/requirements on their part.

Andreas -- What are the current requirements for add-on developers? Do
we require an email address? Statement of licensing regarding the code
we host for them?


Thanks,
--R


More information about the LibreOffice mailing list