On Fri, Oct 12, 2018 at 01:06:41PM +0200, Cor Nouws wrote:
Bjoern Michaelsen wrote on 12-10-18 12:08:
Yes, please. That document is already exploring the rarest cornercases:
- Bookkeeping a bazillion entries of metadata shouldnt be an end to itself:
The webpage should handle metadata about extensions, if there is a reasonable
usecase for using it e.g. in a query. However even basic querying -- apart
from maybe for tags -- is already an advanced feature that 99% of users wont
use.
- If metadata is extracted for search and querying, it should be parsed from
So the idea is that Ask. will do that?
Well, the first question is: do we need all that metadata at all? It would only
be useful if its of help in meaningful queries by users. Once we found that
there is a useful query which requires the website to be aware of metadata
about an extension and have a realistic meaningful usecase for that -- and only
then -- we should decide on implementing that[1].
The second question then is how to get that metadata. E.g. the license has to
be in the extension itself. So why bothering to ask the uploader about it,
possibly causing even mismatched metadata, because the manual entry had a
different value than what is in the metadata of the extension itself.
But more broadly my point is: We should start with a MVP[2] and then extend
upon that as we find meaningful user stories (features) to add. That also means
we should ONLY add metadata when we need it and also have a fetaure that makes
having that metadata useful.
Having a metric ton of metadata "just in case" we _might_ _possibly_ use it one
day is BAD. Asking uploaders for huge amount of metadata in errorprone manual
entry is WORSE, esp. if that metadata is not useful for meaningful queries.
So this is more about how to do iterative development: Start with a minimal
core feature set and make that right, and then incrementally add features one
by one. Do NOT start to collect metadata for the next feature "just in case", if
you havent completed putting the metadata from the current feature to best use
in queries etc.
Essentially, we never want to burden users with having to provide metadata, if
that metadata is not needed for a relevant and useful query to find extensions.
FWIW, this is mostly irrelevant for a decision between Askbot or Plone. For
that the relevant question is: For which do we find more contributors and
moderators and as means of last resort: commercial external support.
Best,
Bjoern
[1] E.g. Sure: we can query extension for the license they are published under
and only list those that have one specific license. But is there a
realisitic use case for that? How many people will do that really?
[2] https://de.wikipedia.org/wiki/Minimum_Viable_Product
--
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
- Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org (continued)
Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org · Bjoern Michaelsen
Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org · Bjoern Michaelsen
Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org · Andreas Mantke
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.