Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


Sorry forgot to add CC's so forwarding it to you guys, please respond on QA
list.


Best,
Joel

---------- Forwarded message ----------
From: Joel Madero <jmadero.dev@gmail.com>
Date: Fri, Mar 29, 2013 at 9:51 AM
Subject: Re: Libreoffice-qa Digest, Vol 21, Issue 51
To: Libreoffice-qa <libreoffice-qa@lists.freedesktop.org>


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
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. 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
directly


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)


Best,
Joel







----------

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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa




-- 
*Joel Madero*
LibreOffice QA Volunteer
jmadero.dev@gmail.com




-- 
*Joel Madero*
LibreOffice QA Volunteer
jmadero.dev@gmail.com

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.