[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org
- Subject: Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org
- From: "Maarten Brouwers (murb)" <firstname.lastname@example.org>
- Date: Fri, 12 Oct 2018 18:18:24 +0200
- To: Bjoern Michaelsen <email@example.com>
- Cc: Miguel Ángel Ríos Vázquez <firstname.lastname@example.org>, email@example.com
> So tl;dr: This is the design list, we do 1/ "Identify core needs and usecases"
> here. No tools/platform discussion. 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 requirements.
Let’s start with some stake holders (not extensive):
- 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
- 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 enough)
* 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 extensions-site.
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 <firstname.lastname@example.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:
> instead of _only_ considering Plone, because "we always used it" is putting
> people first.
>  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.
>  https://en.wikipedia.org/wiki/Bus_factor
To unsubscribe e-mail to: email@example.com
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/design/
|Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org||Heiko Tietze <firstname.lastname@example.org>|
|Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org||Bjoern Michaelsen <email@example.com>|
|[libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org||Bjoern Michaelsen <firstname.lastname@example.org>|
|Miguel Ángel Ríos Vázquez <email@example.com>|
|"Maarten Brouwers (murb)" <firstname.lastname@example.org>|
|Bjoern Michaelsen <email@example.com>|
- Prev by Date: Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org
- Next by Date: Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org
- Previous by thread: Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org
- Next by thread: Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org