Hi Bjoern,

> So tl;dr: This is the design list, we do 1/ "Identify core needs and usecases"
> here. No tools/platform discussion[1]. Next up would be finding enthusiastic
> people willing to work on this. 

Ok, so one of the core needs you actually emphasise is actual support by 
*multiple* volunteers, not relying on a single person to do moderation and/or 
maintenance, which is currently a problem with extensions.libreoffice.org 
<http://extensions.libreoffice.org/>. Very valid point indeed.

A Q/A site by definition gets a lot of users, and satisfied users turn into 
actual contributors on such sites. Good to learn that it is also maintained 
properly. But from that it doesn’t follow that it is the right tool for the job 
of serving extensions & templates. As the earlier mentioned GDoc pointed out, 
there are other requirements than having moderators and maintainers, even 
though no UGC-site can really exist without them. Having said that, I agree 
with the critiques that the old ‘requirements’-document has way too many 

Let’s start with some stake holders (not extensive):

The users
- Want to find extensions that solve their needs (and that are trustworthy / 
reliable / of quality)
- Want to help users find the best extensions as simply as possible
The extension creators
- Want to make their extension findable
LibreOffice.org <http://libreoffice.org/>
- Wants the site to be maintained well

I believe you came to the design list mainly reasoning problems that 
LibreOffice.org <http://libreoffice.org/> is having with the current 
extensions-site as an organisation. I guess most on this list think primarily 
from a users’ perspective, secondary extension creators perspective. A design 
list-member cannot guarantee any long term support from maintainers (requires 
technical skills) and moderators (requires experimentation), although they may 
be able to point out why a current solution is not working well for any of the 
people involved (although again, maintenance is quite a different skill). I’d 
like to assume that a popular site should be able to get the (possibly paid) 
maintenance it requires.

A pragmatic approach to this problem, which I believe you’re after, requires 
not only design list involvement, but also people who want to maintain (and or 
build) it, otherwise we’re after a waterfall style approach where the design 
team is thinking of great features which are too hard to implement and will 
never turn into something that is properly realised.

From what I can see now: adapting ask.libreoffice.org 
<http://ask.libreoffice.org/> requires way more effort to turn it into a proper 
extension-site than either adapting the current extensions-site or adopting an 
existing solution of another project, because I believe ask.libreoffice.org 
<http://ask.libreoffice.org/> currently lacks:

* Structured storing of metadata, most importantly: versions that it works 
with, screenshot(s), authorship, license, links to further documentation / 
source (automatically extracted or not)
* Listing should feature part of this metadata directly (title and votes is not 
* Should communicate ‘Extensions-site’ (it should at least quack like a duck if 
it wants to be a duck), not Q/A
* Clear separation of certain categories (most importantly Extensions & 
Templates, but I could imagine Language support as another main category, not 
just a random collection of ’tags’)

I was unaware of the extensions’ site problem with lack of volunteers actually. 
Some call for volunteers in that respect there would help :) To be honest, I 
don’t even have extensions installed. I think it is partly caused by the lack 
of end-user centric design; as extensions weren’t really well promoted in the 
first place it looked a bit amateurish. I’m actually able to help there (as a 
front-end developer) and think a few things would help a lot already:

* First and mostly: Remove the focus from ‘most recent’ and focus on most 
popular; currently some 
* Allow for more (high resolution) screenshots that can better communicate what 
the extensions are doing
* Promote the download link
* Downplay ‘requirements’ if those requirements are being fulfilled by the 
default installations of 5.x and greater release already (isn’t Python UNO part 
of the default installation?)
* Ask for moderators on the site if there aren’t really any :)

I’d hope that more volunteers would follow from a more used & usable 

Maybe we should move the discussion to a spot where all stakeholders and 
potential volunteers are involved. I’m happy to subscribe to that spot :)



> Op 12 okt. 2018, om 16:02 heeft Bjoern Michaelsen 
> <bjoern.michael...@libreoffice.org> het volgende geschreven:
> Hi Maarten,
> On Fri, Oct 12, 2018 at 02:06:54PM +0200, Maarten Brouwers (murb) wrote:
>> What about adapting Mozilla’s extension-site? 
> So lets phrase the problem differently: We are not lacking tools or platforms.
> We are lacking volunteers to maintain, develop and moderate on platforms. So 
> if
> you find a team of 2 to 3 enthusiastic volunteers that are willing to push a
> platform forward that is great. That platform can be Mozilla Addons, Askbot,
> Plone or something else.
> OTOH that is for later: This is the design list and the focus should be on
> identifying the vital core features needed on a solution. I opened the
> discussion with Askbot as it provides this:
> - We currently have a well-maintained instance.
> - We currently have active moderators on that site.
> - We were able to purchase development on AskBot.
> So the workflow has to be:
> 1/ Identify core needs and usecases
> 2/ Find volunteers, enthusiasts and maintainers, who can provide these core
>   usecases with ~whatever tool they want.
> 3/ Implement MVP on a platform and extend usecases as volunteer resources 
> allow
>   (maybe topped up with some payed development, if that is worth it)
> The tools are NOT the important part of this. People are. Considering AskBot,
> which has 100 to 1000 moderators:
> https://ask.libreoffice.org/en/badges/14/supporter/
> https://ask.libreoffice.org/en/badges/9/critic/
> instead of _only_ considering Plone, because "we always used it" is putting
> people first.
> Best,
> Bjoern
> [1] And again: Saying "Do not limit yourself to Plone" is exactly that: It
>    keeps the tools out of a discussion that should identify core usecases.
> [2] https://en.wikipedia.org/wiki/Bus_factor

To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/design/
Privacy Policy: https://www.documentfoundation.org/privacy

Reply via email to