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?

>   the extension itself and not manually entered (or even duplicated: most of
>   the stuff is already in the extension itself)
>> Define the different users and what they want.
> 99% of extensions are:

well, maybe 95+%.

> - single revision
> - single author
> - cross platform
> That is the usecase we should optimize for. Adding features for the 1% other
> extensions should not be done if it adds complexity for the majority of
> uploaders.

If adding limited number of extra features is simple, and doesn't put a
burden on all users, that would be fine.

> So in fact, half of the features in the google doc should be moved aside for
> really, really pinning down a simple workflow for those 99% of uploaders that
> wrote some single revision StarBasic or Python extension on their own.

So practical: the design, and thus the UI burden, can be reduced by
skipping the project-idea. A project is useful for an extension that has
more revisions, maybe for various versions of LibreOffice. But in those
cases, the maker of the extension can just upload another one, and add a
note to the previous version about the new one.
Things like that.


Cor Nouws
GPD key ID: 0xB13480A6 - 591A 30A7 36A0 CE3C 3D28  A038 E49D 7365 B134 80A6
- vrijwilliger
- volunteer
- Member Board The Document Foundation
- /

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
Privacy Policy:

Reply via email to