[Libreoffice-qa] Libreoffice-qa Digest, Vol 21, Issue 51

Joel Madero jmadero.dev at gmail.com
Fri Mar 29 09:51:55 PDT 2013

I'm adding Andreas Mantke to the discussion as he is the admin of the page
so can give better feedback of the possibilities.

@Andreas - the thread is a bit long so apologies that it's a bit of a time
consuming read. I think what is for sure at this point is we would like to
know how difficult a couple things would be to add to the template site:

1) Comments - talking to Cor this seems quite difficult and we understand
if it's outside of the scope of our current man power.

2) An "official" badge that will be prominently displayed on templates that
    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. I think Cor
has a valid point that we need to understand what we (QA) can handle in
terms of testing and supporting extensions. This is a further discussion
that needs to happen within QA.

3)  "Contact Developer" button that would somehow contact the developer

> The basic problem is that bugs are filed against Extensions and
> Templates in the same manner as bugs filed against LibreOffice proper.
> We had general agreement that the developer of the Extension should be
> responsible for dealing with his own bugs, but there are some wrinkles
> and caveats:

Leaving this just for summary for anyone else reading, it sums it up nicely.

> * There are some Extensions that are bundled with LibreOffice – these
> are clearly within our scope to support, even if author has quit
> developing the Extension
> * Here are some suggestions on what to do with Extensions that
> LibreOffice does not officially support:
> 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)

> 2. New Product for “Extensions” on FDO
>     -Add an entirely new product on FDO for Extensions
>     -Some concern that this will not help QA at all and will only confuse
> users
>     -Another potential issue is if we have a contract with FDO for 1
> product (not sure)
>     -Another issue is that we would use component for this product for
> each extension, meaning we would have >150 components. Lots of work
> for QA to sort
> 3. Add a New Component (Official Extensions vs. Unofficial)
>     -Official would be our bug, unofficial would get #1 option applied

Both these options seems quite complicated IMO. I think it wouldn't help QA
much, it would confused users and clog up FDO with additional things.
Furthermore concerned about our FDO agreement.

> Other Notes
> * 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.

> 1) It's really important that we be up-front with our users about the
> kind of support that they can expect for a particular add-on or
> extension.

+1, I think this is the primary focus, the additional work is secondary to
making it crystal clear to users what we support, how we support it, and
what they can expect in the future.

> 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"

> Here are the different approaches:
> 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.

> B) We clearly and explicitly inform users about which
> Extensions/Templates have official support and which ones have
> unofficial support from the developers themselves.

+1, I think with the above comment (for A) we can indeed synthesize these
two into one functional process)


> ----------
> A) We provide a strict structure for the Extensions/Templates sites
> that integrates extension developers into our process.
> In this approach we would curate the add-on sites and provide some
> assurances regarding user support.
> Developers wishing to add Extensions or Templates would become the
> maintainer for the extension and be required to supply
> - And email address
> - A Bugzilla account
> - Some kind of guarantee on how long they'll be willing to support the
> add-on
> Any bugs filed against the extension would be assigned to the
> maintainer(s) of the extension.
> We could ping maintainers of Extensions from time to time (e.g.
> whenever we bump the minor version number), and check-in to make sure
> that
> - They're still interested in providing support
> - They're interested in porting the extension to the new release of LO
> (if necessary)
> If an extension falls into disrepair, we could
> - Remove the extension
> - Grey-out the extension page and/or put some big warnings on it
> - Offer other developers the opportunity to assume the maintainer role
> for this extension
> B) We clearly and explicitly inform users about which
> Extensions/Templates have official support and which ones have
> unofficial support from the developers themselves.
> Instead of (or perhaps in addition to) requiring developers to assume
> a maintainer role for the extensions they author, the add-ons sites
> would include much more details and use clear symbols like badges to
> let users know if an extension has Official Support, or Unofficial/No
> support. We make this information VERY prominent on the page, so that
> they're fully aware of what kind of support to expect BEFORE they even
> install an extension.
> We could provide extension developers some kind of opt-in system
> whereby they would be able to indicate to the user their commitment to
> support the software.  (I'm not sure how this would work -- perhaps
> the developer would just have to ping us, or perhaps it would be some
> kind of formulaic thing based on how much positive/negative feedback
> the developer or his extensions had received).
> In this approach, if a bug is filed against an Unsupported extension
> for which we have no developer contact, we mark the bug as NOTOURBUG,
> politely point the user to the extension page, and indicate that the
> extension is Unsupported.
> ----------
> Thoughts on these proposals?
> Cheers,
> --R
> _______________________________________________
> Libreoffice-qa mailing list
> Libreoffice-qa at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa

*Joel Madero*
LibreOffice QA Volunteer
jmadero.dev at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice-qa/attachments/20130329/e5a1d7e4/attachment-0001.html>

More information about the Libreoffice-qa mailing list