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


Hi,

On Fri, Oct 12, 2018 at 04:45:51PM +0200, kainz.a wrote:
When I look at popular webpages where you can share your content like image
webpages, openclipart, ... they are all very simple. 
[...]
The page can be used for extensions, templates, documentations, ...

Yes.

So Im going to discuss tools/platforms here one more time -- mostly to show how
futile it is to discuss platforms and feature checklists. ;)

E.g. a well-configured discourse.org forum could likely replace:
- Nabble forums
- Extension hosting
- Template hosting
- AskBot

Still, I would object to simply "setup an instance" hard. Why? Because it would
be yet-another-platform to maintain. The discourse maintainer would shout at
the askbot maintainer that they should stop their stuff and really help with
discourse. The askbot maintainer would shout at the Plone maintainer to stop
their stuff and really help with askbot. The Plone maintainer would shout at
the discourse maintainer to stop their stuff and help with Plone.

Content (accounts, posts and entries) is king. Adding new CMSes without
migrating old content over to it is splitting up our volunteer forces and
leaving us with too little on all of them.

So, to allow our volunteers to build awesome platforms, we need to have them
focused. This is why consolidating content is important: If we have fewer
platforms, we can have more hands and more content on those. Also, it makes it
easier to migrate should we need to change platforms again someday, if our
content is on fewer platforms.

As such, wrt the "identify core usecases" task for the design mailing list, it
is really about identifying the essential core functionality that we cannot
live without and that have to be kept even over a migration to a new
platform. Setting up a new platform requires having a plan to migrate existing
content and user accounts. The fewer existing platforms need to be migrated,
the better. Therefore adding platforms is always a burden for the future.

The design mailing list OTOH should not be so much about identifying
"nice-to-have"s. As a volunteer project, we do not have to priotize those: They
get done, if a volunteer is excited by the idea and spends his time to
implement it.

Best,

Bjoern

-- 
To unsubscribe e-mail to: design+unsubscribe@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

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.