<div dir="ltr"><div><span style="font-family:arial,sans-serif;font-size:12.666666984558105px">I'm adding Andreas Mantke to the discussion as he is the admin of the page so can give better feedback of the possibilities. </span></div>
<div><span style="font-family:arial,sans-serif;font-size:12.666666984558105px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.666666984558105px">@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:</span></div>
<div><span style="font-family:arial,sans-serif;font-size:12.666666984558105px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:12.666666984558105px">1) Comments - talking to Cor this seems quite difficult and we understand if it's outside of the scope of our current man power.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:12.666666984558105px"><br></span></div><div><font face="arial, sans-serif"><span style="font-size:12.666666984558105px">2) An "official" badge that will be prominently displayed on templates that are:</span></font></div>
<div><font face="arial, sans-serif"><span style="font-size:12.666666984558105px"> a) bundled with LibreOffice</span></font></div><div><font face="arial, sans-serif"><span style="font-size:12.666666984558105px"> b) Meet some other criteria that is to be determined by QA</span></font></div>
<div><font face="arial, sans-serif"><span style="font-size:12.666666984558105px"><br></span></font></div><div><font face="arial, sans-serif"><span style="font-size:12.666666984558105px">*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.</span></font></div>
<div><font face="arial, sans-serif"><span style="font-size:12.666666984558105px"><br></span></font></div><div><font face="arial, sans-serif"><span style="font-size:12.666666984558105px">3) "Contact Developer" button that would somehow contact the developer directly</span></font></div>
<div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
The basic problem is that bugs are filed against Extensions and<br>
Templates in the same manner as bugs filed against LibreOffice proper.<br>
We had general agreement that the developer of the Extension should be<br>
responsible for dealing with his own bugs, but there are some wrinkles<br>
and caveats:<br></blockquote><div><br></div><div style>Leaving this just for summary for anyone else reading, it sums it up nicely.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
* There are some Extensions that are bundled with LibreOffice – these<br>
are clearly within our scope to support, even if author has quit<br>
developing the Extension<br>
<br>
* Here are some suggestions on what to do with Extensions that<br>
LibreOffice does not officially support:<br>
<br>
1. Close as NOTOURBUG + comment to contact extensions author<br>
-Remember some extensions are bundled with LibreOffice<br>
-Here adding ability to have “comments” on extensions would be<br>
great so that users could directly get in touch with extension<br>
developers<br>
-If comment not available, having an easy “contact author” button<br>
would be good<br></blockquote><div><br></div><div style>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)</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
2. New Product for “Extensions” on FDO<br>
-Add an entirely new product on FDO for Extensions<br>
-Some concern that this will not help QA at all and will only confuse users<br>
-Another potential issue is if we have a contract with FDO for 1<br>
product (not sure)<br>
-Another issue is that we would use component for this product for<br>
each extension, meaning we would have >150 components. Lots of work<br>
for QA to sort<br>
<br>
3. Add a New Component (Official Extensions vs. Unofficial)<br>
-Official would be our bug, unofficial would get #1 option applied<br></blockquote><div><br></div><div style>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. </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
Other Notes<br>
<br>
* Having an “official badge” was discussed, would be a really useful<br>
addition to extension site<br></blockquote><div><br></div><div style>+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. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
* If author has abandoned their extension, we can either delete the<br>
extension if it's broken or make bug report an enhancement if another<br>
developer wishes to fix it<br></blockquote><div> </div><div><br></div><div style>Deletion IMO is no good, leaving it up but doing "something" to say "currently broken, looking for developer to fix it" would be best. </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<br>
1) It's really important that we be up-front with our users about the<br>
kind of support that they can expect for a particular add-on or<br>
extension.<br></blockquote><div><br></div><div style>+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.</div>
<div style> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
2) We need to communicate our strategy clearly and effectively to<br>
other teams in the LibreOffice project (e.g. the volunteers on the Ask<br>
site), so that we all provide a complete and consistent message to end<br>
users.<br></blockquote><div><br></div><div style>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" </div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Here are the different approaches:<br>
<br>
A) We provide a strict structure for the Extensions/Templates sites<br>
that integrates extension developers into our process.<br></blockquote><div><br></div><div style>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. </div>
<div style> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
B) We clearly and explicitly inform users about which<br>
Extensions/Templates have official support and which ones have<br>
unofficial support from the developers themselves.<br></blockquote><div><br></div><div style>+1, I think with the above comment (for A) we can indeed synthesize these two into one functional process)</div><div style><br>
</div><div style><br></div><div style>Best,</div><div style>Joel</div><div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
----------<br>
<br>
A) We provide a strict structure for the Extensions/Templates sites<br>
that integrates extension developers into our process.<br>
<br>
In this approach we would curate the add-on sites and provide some<br>
assurances regarding user support.<br>
<br>
Developers wishing to add Extensions or Templates would become the<br>
maintainer for the extension and be required to supply<br>
- And email address<br>
- A Bugzilla account<br>
- Some kind of guarantee on how long they'll be willing to support the add-on<br>
<br>
Any bugs filed against the extension would be assigned to the<br>
maintainer(s) of the extension.<br>
<br>
We could ping maintainers of Extensions from time to time (e.g.<br>
whenever we bump the minor version number), and check-in to make sure<br>
that<br>
- They're still interested in providing support<br>
- They're interested in porting the extension to the new release of LO<br>
(if necessary)<br>
<br>
If an extension falls into disrepair, we could<br>
- Remove the extension<br>
- Grey-out the extension page and/or put some big warnings on it<br>
- Offer other developers the opportunity to assume the maintainer role<br>
for this extension<br>
<br>
<br>
B) We clearly and explicitly inform users about which<br>
Extensions/Templates have official support and which ones have<br>
unofficial support from the developers themselves.<br>
<br>
Instead of (or perhaps in addition to) requiring developers to assume<br>
a maintainer role for the extensions they author, the add-ons sites<br>
would include much more details and use clear symbols like badges to<br>
let users know if an extension has Official Support, or Unofficial/No<br>
support. We make this information VERY prominent on the page, so that<br>
they're fully aware of what kind of support to expect BEFORE they even<br>
install an extension.<br>
<br>
We could provide extension developers some kind of opt-in system<br>
whereby they would be able to indicate to the user their commitment to<br>
support the software. (I'm not sure how this would work -- perhaps<br>
the developer would just have to ping us, or perhaps it would be some<br>
kind of formulaic thing based on how much positive/negative feedback<br>
the developer or his extensions had received).<br>
<br>
In this approach, if a bug is filed against an Unsupported extension<br>
for which we have no developer contact, we mark the bug as NOTOURBUG,<br>
politely point the user to the extension page, and indicate that the<br>
extension is Unsupported.<br>
<br>
----------<br>
<br>
Thoughts on these proposals?<br>
<br>
<br>
Cheers,<br>
--R<br>
<br>
<br>_______________________________________________<br>
Libreoffice-qa mailing list<br>
<a href="mailto:Libreoffice-qa@lists.freedesktop.org">Libreoffice-qa@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa" target="_blank">http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><b><font face="garamond, serif" size="4">Joel Madero</font></b><div><font face="garamond, serif">LibreOffice QA Volunteer</font></div><div><font face="garamond, serif"><a href="mailto:jmadero.dev@gmail.com" target="_blank">jmadero.dev@gmail.com</a></font></div>
<div><br></div></div>
</div></div>