Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

Hello Andreas,

Thanks for joining the discussion.

On Sat, Nov 03, 2018 at 10:56:56PM +0100, Andreas Mantke wrote:
> FYI: because I felt this way of communication inside the project lacked
> the necessary respect for the volunteer work done for about seven years
> during spare time, I stopped my work for the project and the website
> with immidiate effect. I was never included in any discussion about the
> site before this thread (or better threat) was started. I think this is
> a behavior that is not appropriate to an open source project that define
> itself as open and transparent.

Im sorry that you feel that way. However, the Board and -- I am sure the
community too -- are deeply grateful for your work here; and as you've been a
member of the Board from the start, you were included in all discussions --
both internal and external -- about the struggle around that site though.

The Good Thing is, this thread did yield at least three volunteers from the
LibreOffice community wanting to help out with the extension website now that
they are aware: Maarten, Ilmari and Andreas Kainz. From what I heard, some have
tried to contact you on how to get involved or proceed, but unfortunately were
unable to succeed.

> Thus the extensions and templates website is not maintained since three
> weeks yet. I will only spend my spare time for tasks where I get in
> return respectful treatment and honest feedback.

That is of course deeply unfortunate, but I thank you that you inform us about
this now. Checking back, I learned the TDF infrastructure team is already aware
of this, but still lacks some bits and pieces of how to operate the site - would
be great if you can share those with them, here or in private, so that that
handover can be closed.

Beyond the immdiate issues: Thank you for the time and the work you put in the
extension website over the all the years. For all the other stuff going on in
the project, we often lost sight of it being an important entrypoint to the
community and the ecosystem around LibreOffice.

Whatever the volunteers of the LibreOffice community come up with for the
future of hosting LibreOffice extensions, we would be happy to welcome you
back to that someday.

Best,

Bjoern

-- 
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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

Hi,

On Sun, Oct 14, 2018 at 03:54:13PM +0200, Maarten Brouwers (murb) wrote:
> Sure, but again, I doubt it matters to an extensions website. Mozilla has no
> OAuth, and still has imho a great extensions website. In an ideal world
> everyone contributes and consumes, but in reality it is just a small
> percentage. Especially when it comes to more complicated stuff like building
> extensions and quality themes.

Mozilla has an full discourse forum for extensions:

- https://discourse.mozilla.org/c/add-ons

which allow signing on with Firefox/Github/Google and plain email.

> Interaction & users should imho not be the primary goal for an extensions
> website, great extensions should be.

There is nothing an extension website can do to improve the content uploaded to
it as long as the upload is resonably simple. ... Except building a broad
community (users) and easy feedback, discussion and cooperation (interactions).

Best,

Bjoern

-- 
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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

Hi Maarten,

On Sun, Oct 14, 2018 at 01:55:38PM +0200, Maarten Brouwers (murb) wrote:
> Maintaining software doesn’t become easier when you build a complex tool (an
> extensions website) on something that isn’t meant for it (a Q/A site).

Its really simple:

Dont tell others "Do not consider askbot/nextcloud/discourse".
I will not tell others "Do not consider plone" either.

Decisions will have to be made on the result in the end, which are: content,
users, interactions. However a team delivers that from the tech side is
irrelevant to the decision[1]. I will gladly support a platform that I dont like
technically, if it delivers results.

Best,

Bjoern

[1] Modulo some annoying things like e.g. legal or security considerations.

-- 
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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

Hi,

addendum:

On Sun, Oct 14, 2018 at 02:14:36PM +0200, Bjoern Michaelsen wrote:
> For the community the decision should go with the team that gets the most
> content, interaction and users on their platform. I dont care if someone 
> thinks
> the platform was not made for the task -- it there is a team that makes the
> experience awesome and grows content, users and interaction on it.

the caveat being that in general having more platforms is worse than having
one, as it splits the community and causes friction. So we shouldnt just let
everyone run with their proposal and then end up with five extension websites,
which are all badly maintained by too small teams.

But: For making that call, a team argueing "we can grow content, users accounts
and interactions with $foo" ~always trumps "I think platform $bar was
originally made for the task."

Best,

Bjoern

-- 
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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

Hi,

On Sun, Oct 14, 2018 at 01:24:10PM +0200, Maarten Brouwers (murb) wrote:
> I got a bit different impression, and still see the extensive requirements
> doc (also the new one) highly contrasting with what I read as the idea of
> ‘just start iterating from ask.libreoffice.org ’
> (I know, no-one said that as simply). Sure you can do your bookkeeping in
> Writer, no need for Calc (or Base), but I just wonder if you should even
> considering starting with Writer.

Stating that a classic CMS is by definition better suited for the task at hand
than something more interactive like discourse is a foregone conclusion. Given
that the lack of community involvement is the core reason for many limitations
of the current setup, its not a valid one.

> - Lack of integration with LibreOffice? -> Create an API on top of the
> current database and integrate it with LibreOffice (another thing that I
> guess would be hard to realize with a foundation based on Askbot)
> [...]
> - Lack of moderators? -> All of the above?

Please dont guess or speculate on this, you will likely get it wrong. This is
something that needs to be evaluated by trying. To get integration with
LibreOffice right, the API or hosting is the smallest problem.

The hard problems are:
1/ verification of content (Codereview by humans)
2/ signing of content (ensuring that what was review is what is installed)

Again: Hosting and even integrating this is easy, compared to the social task
of verification, feedback and interaction. As such, the platform underneath is
not much of a relevant destinction -- unless on the latter. Reviewing or even
casual reviewing is the hard part. It requires manpower => which requires an
active community => which requires a platform that encourages interaction.

> I really doubt that OAuth or not has anything to do with it. Localisation, 
> probably yes.

Well, where do the 45.000 accounts on askbot come from? The site is far from
being perfect, but still doing better that all other forums we have. OAuth etc.
certainly has a role in that, as does gamification, badges and social media
integration.

Finally, it should be obvious that is better to do custom development on our
specific (extension hosting) needs on a platform that provides broad generic
features (social media integration, gamification, oauth) than using a specific
platform for "extension hosting" and trying to add a lot of missing generic
features to it. The reason is doing custom development for social media
integration, gamification, OAuth will drown us in constant maintainance of those
custom build features.

Anyways: The start of this thread was "please consider more than one platform"
and the repeatedly given rationale is that bringing together users and content
are harder than bringing together moderators and maintainers and that is harder
than customizing a base technology. This remains universally true and as such
please stop speculating about the base technologies in a way that tries to
suggest to only use one technology.

For the community the decision should go with the team that gets the most
content, interaction and users on their platform. I dont care if someone thinks
the platform was not made for the task -- it there is a team that makes the
experience awesome and grows content, users and interaction on it.

Best,

Bjoern

-- 
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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

Hi,

On Sat, Oct 13, 2018 at 01:14:09PM +0200, kainz.a wrote:
> Is it possible to use libreoffice online and nextcloud for templates and
> extensions?

as said: You can host stuff on pretty much any platform. However, nextcloud
originated with a mission closer to a plain Filehosting/Intranet a la
Sharepoint or maybe Dropbox(*). That is even _less_ interactive for a broad 
public
than CMSes like Silverstripe/Wordpress/Plone. And Askbot and e.g. discourse.org
are more interactive for a public audiences than CMSes by default.

That -- and the fact that we have 45.000 accounts on it -- are the reason I
brought up Askbot. Content and accounts are the things that are hard earned on a
platform, maintainers and moderators are a bit easier, but still hard. The
pure technical platform is the easiest part.

Best,

Bjoern

(*) Those are a good fit for cooperation of a smallish group, e.g. a company or
TDF members though. Less so for involving $RANDOM_INTERNET_PERSON with the
project and the community.

-- 
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

Re: [libreoffice-design] Requirements for extension site

[Bjoern Michaelsen]

Hi Heiko,

On Sat, Oct 13, 2018 at 09:52:01AM +0200, Heiko Tietze wrote:
> Based on these insights we created a new document for a new hosting platform.
> The document is shared on
> https://nextcloud.documentfoundation.org/s/E5RX5xK6jxQPLdK and open for
> discussion.

Thanks for sharing that.

That looks indeed like a very promising approach to finding the core 
functionality
that is needed.

Best,

Bjoern

-- 
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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

Hi,

On Fri, Oct 12, 2018 at 10:45:48AM -0600, Taylor Jenkins wrote:
> The only way, architecturally, that I see ask.libreoffice.org being able to
> play a role in an extension repository, is if the uploaded extensions were
> stored to a remotely queriable database for access by a separate front end
> at libreoffice.org. In fact, it would be really great if the
> ask.libreoffice.org message board could also be embedded in this front end,
> to make for a seamless UX.

Yes, those are some of the benefits I was considering. Especially as Askbot
provides some commenting, feedback and wiki functionality that the current
extension website is missing.

Best,

Bjoern

-- 
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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

Hi,

On Fri, Oct 12, 2018 at 09:48:35PM +, toki wrote:
> Until/unless the search function on ask.libreoffice is fixed, migrating
> there is going to ensure that absolutely, positively ensure that nobody
> will ever find the extension that they are looking for. 

That is not really an argument against _evaluating_ AskBot as a platform.
Evaluating means looking into what can be done with a platform and what the
challenges are.

Beyond that, I have to say I am not too surprised that finding something in
Askbots 29000 entries is task a bit harder than finding a template in the ...
twelve[1] templates hosted on the extensions website.

Proper tagging (which can be done programmatically) should make twelve
templates searchable with AskBot even if it misses things sometimes with 29000
other entries.

Best,

Bjoern

[1] "Currently there are 12 LibreOffice template project(s) with 20 release(s) 
available."
https://extensions.libreoffice.org/ 

-- 
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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

Hi,

On Fri, Oct 12, 2018 at 06:18:24PM +0200, Maarten Brouwers (murb) wrote:
> From what I can see now: adapting 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

I dont think we should speculate on this too much without giving it a try.
Given the things missing on the extension site (OAuth Logins etc., user
feedback on content) its still a long way to go. FWIW, as noted, the AskBot
site is already capable to host templates, and allows some of the things
missing on the current extension site.

As such, improving the extension website is a good thing. But IMHO we should
also look into what can be done with AskBot starting with evaluating template
hosting. Evaluating means just that: to learn what is possible.

> 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
> . Very valid point indeed.

Yes.

> I was unaware of the extensions’ site problem with lack of volunteers
> actually. Some call for volunteers in that respect there would help :)

You can pretty much assume that all parts of the LibreOffice always have use
for volunteers. ;)

> I’m actually able to help there (as a front-end developer) and think a few
> things would help a lot already:
> [...]
> I’d hope that more volunteers would follow from a more used & usable 
> extensions-site.

That is most appreciated! The more volunteers try themselves on working with our
systems, the better we can decide on how to proceed.

Best,

Bjoern

-- 
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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

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+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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

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.

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. For the most part, they can use whatever tool
they want, if they get stuff done. Even if I think their tool is horrible or
"a bus turned into a car", I am happy, if the users of the site are happy and
there is an active set of volunteers[2] maintaining it.

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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

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+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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

Hi,

On Fri, Oct 12, 2018 at 12:08:32PM +0200, Bjoern Michaelsen wrote:
> 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.

Or rather:

Split the document up in two sections: First one for:

- single author
- single revision
- cross plattform

uploads (99%), the second for everything else (1%). You can create persona for
these two uploaders too, if it makes you happy.

Best,

Bjoern

-- 
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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

On Fri, Oct 12, 2018 at 11:28:08AM +0200, kainz.a wrote:
> for the basic UX there are still some ideas from the design team
> https://docs.google.com/document/d/12dbdmzi3dy5TwNsIao0MXZSnl7X4jMk5zKwy8Azeohg
> (sorry that it is on gdocs)

Commented.

> And please keep it simple.

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
  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:
- 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.

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.

Best,

Bjoern

-- 
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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

Hi,

On Fri, Oct 12, 2018 at 08:23:52AM +0200, kainz.a wrote:
> For me templates and extension didn't have the same "developer" group.
> extensions should have ongoing releases so a git orientated workflow is
> more usefull. The source of a lot extensions are on githab or gitlab, ...
> Templates will be done by office users so an simple upload will be usefull.

Yes, source hosting is another issue -- and one were neither Plone nor Askbot
provide an solution yet. If an extension developer publishes on github/gitlab
anyway, I think their main remaining need is discoverability.

We see that on the existing extension webpage, were a lot of content was not
hosted on extensions.libreoffice.org, but just linked to
github/gitlab/whereever. Both Plone and Askbot can provide that, but the Askbot
experience is much simpler because of e.g. OAuth login, distributed moderation,
discussion/mini-wiki being available.

So, I wouldnt want to block on solving the source-hosting problem for now and
leave it for later. Lets solve the basic UX first.

> Another big question is about development. Which platform supports a
> community orientated development, which mean when there is a group how do
> they work together on the webpage / platform. As example Andi do the
> extension page maintanance someone would like to play around with different
> design layouts, does the platform support cooperative work and an
> "playground" for new developments?

I think this is the key here: So far, Andi being a lone warrior here has been
the limiting factor -- not by lack of skill, but by being alone. If there are
multiple people willing to work on this with Plone, that is great. But at this
point, I would not want to turn down a solution based on e.g. Askbot if that
shows more prospect.

Best,

Bjoern

-- 
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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

Hi,

On Thu, Oct 11, 2018 at 09:16:34PM -0300, Daniel A. Rodriguez wrote:
> So, if the problems are well known and no platform cover all the
> project needs, what about a tender to get something from scratch?

That would broaden the scope of this in major way and increase the change of
failure: If only tenders were always "I write down what I want, pay and get
what I imagined.": But they arent and unfortunately for complex topics like
this one, verifying a tender result is almost as much work as the
implementation itself[1].

Also there is a cost in maintanance that we have to pay (or have to ensure
volunteer to be available for) for each and every CMS we host. That cost is
higher the more different CMS we have and the more customized our workflows on
them are.

We currently have:
- Silverstripe for static content
- Wordpress for news
- MediaWiki for project development resources (development on LibreOffice 
itself)
- Askbot (content on top of LibreOffice)
- Plone

Best,

Bjoern


[1] Also, as migration paths are hard, there is a certain risk this will end as
https://xkcd.com/927/

-- 
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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

Hi,

On Thu, Oct 11, 2018 at 09:27:09PM -0300, Ricardo Dos Santos wrote:
> Is there a possibility of an adaptation of the pages and continue using
> Plone?
> Or the effort does not pay?

In theory, you can build pretty much anything on any platform or language. In
practice, the available volunteers are limiting what can be done.

Andi is neither stupid nor missing enthusiasm, but he is ALONE and has been for
years. So despite his heroic effort, what can be accomplished for the extension
website is limited compared to what is likely possible with other platforms
(where there might be more features available out-of-the-box and more
volunteers able or willing to contribute).

This is why other platform should be IMHO considered too.

Best,

Bjoern

-- 
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

Re: [libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

Hi Miguel,

(you do not seem to be subscribed to the design@ list, so others will not see
your mail. I will reply anyway, but please consider subscribing to the mailing
list when discussing there.)

On Thu, Oct 11, 2018 at 10:56:43PM +0200, Miguel Ángel Ríos Vázquez wrote:
> Can we really think about using Ask for that?

yes. The problems are well-known, have repeatedly communicated in the project
since at least 2013. There really isnt any news here. Unfortunately, there has
been little movement, the community around the old extension webpage did not
grow despite efforts to do so and even external commercial support wasnt
unlocking the situation.

OTOH, my mail clearly stated that I would like to invite the design team to
consider thinking outside of the box and ALSO think about ask.libreoffice.org
as a platform. This e.g. doesnt mean that the old Plone site _needs_ to die --
but it should not be the only platform considered to provide the much needed
content hosting.

If this results in three to four people volunteering to push the old page
forward in a coordinated effort, I am a happy bunny. BUT: Given this has been
tried since 2013 at least and given the feedback I heard from even commercial
suppliers about the state of things, I am not too optimistic.
 
> My impression is that it is not even very well accepted as a forum. Not an
> example of success.

Impressions are odd in that. ask.libreoffice.org is certainly the most
successful forum LibreOffice currently hosts. 

https://ask.libreoffice.org/en/users/ shows currently 1547 pages of 30 users
each, so >45.000 registered accounts on ask.libreoffice.org. For comparison:
wiki.documentfoundation.org has ~17.000 accounts. I'd assume all other TDF
infra has less accounts.

https://ask.libreoffice.org/en/questions/ has >29.000 _english_ questions
alone. For comparision: wiki.documentfoundation.org has ~22.000 pages in all
languages.

While there is always room for improvement, ask.libreoffice.org is our most
successful platform -- by far.

> And on the other hand we could be more thankful with the volunteer work of
> the people in the project, whether we like it or not.

That is also true for those content creators trying to use the extension
website to publish content. I posted some random tweets that show their
experience. Unfortunately, that feedback isnt too hard to find and has been
around for years. People uploading their first extension or template are
newcomers to the community -- and as active contributors we should make sure
their experience is not too aweful. The tweets -- together with the fact that
so many extensions and templates are hosted elsewhere (e.g. on github) shows
that we are loosing contributors and miss the opportunity to integrate them
with the wider community. We let those future contributors down.


So: tl;dr: I encouraged the design team to look ALSO look at ask.libreoffice.org
for allowing content publication, esp. since we had good past experience with
getting commercial support for it for well-defined feature requests. That
doesnt rule out Plone as a platform should we (finally) find enough volunteers
for it to gain some more inertia. So if you like the old extension site, feel 
free
to contribute to it (and find some others to do the same).

Best,

Bjoern

-- 
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

[libreoffice-design] Topic for design team to investigate: Content hosting consolidation on ask.libreoffice.org

[Bjoern Michaelsen]

Hello Design Team,

as you might be aware, the user experience of our extension and template
website causes users a lot of concern[1]. This is despite volunteer efforts
trying to move this forward, but stalling due to limited resources, which led
to TDF even attempting to get commercial support for Plone[2] to augment the
the limited volunteer ressources available. The latter did not help to
meaningfully improve the situation either.

So as all current efforts there are stalled, I looked around for alternative
solutions to our usecase -- which is hosting auxiliary content for LibreOffice
consumers. We already have a platform that does that, which is 
ask.libreoffice.org.

ask.libreoffice.org already allows uploading of templates as attachments to
questions, so it can already be used for templates. Doing so (e.g. by posting a
self-answered question) is possible, but not exactly intuitive. However, askbot
also provides:

- various logins including OAuth etc. (which currently is a hassle on Plone)
- distributed moderation and gamification (which currently is a bottleneck on 
Plone)
- better discoveribility, tagging and social media integration
- markdown, mini-wiki and discussion of content
- multi-language support

That is, the experience for template creators and consumers is already much 
better
on askbot than it is on the current extension and templates website, which is
stalled and currently has no clear path to even get to a experience comparable
with askbot -- let alone beyond.

As such, I would like to suggest the design team to investigate, if it is 
feasable:

- to extend askbots existing UI to offer uploading of templates
  (well, technically that is already possible: This is just about making the
  usecase more obvious to users, e.g. with a guided "templates upload wizard")
- to extend askbots configuration to also allow .oxt files as uploads and offer
  the same for extensions
- finally, use e.g. tags to provide a "template" or "extension" view of
  ask.libreoffice.org

Unlike the rather limited successes we had with Plone, TDF sucessfully triggered
improvements of askbot in the past[3], so given some well-scoped choices and
selections made by the design team wrt askbot could help guide the same in the
future.

Best,

Bjoern


[1] Seen e.g. by:
a/ repeated cries for help on twitter, some examples:
   https://twitter.com/nimbleslides/status/1020899933161848832
   https://twitter.com/FloraCanou/status/1020517686453735424
b/ currently no presentation templates being offered there, despite this
   being the most common use case:
   
https://extensions.libreoffice.org/templates?getCategories=Presentation=any
   and massive template collections actually being hosted elsewhere e.g.:
   https://github.com/dohliam/libreoffice-impress-templates
[2] see entry for 2016-02-18 on 
https://wiki.documentfoundation.org/TDF/BoD_Decisions
[3] https://en.wikipedia.org/wiki/Askbot

-- 
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

Re: [libreoffice-design] Re: Minutes of the Design Hangout: 2015-10-07

[Bjoern Michaelsen]

On Fri, Oct 30, 2015 at 07:21:22PM +0400, Yousuf 'Jay' Philips wrote:
> Not sure how well breeze with the ubuntu theme and it maybe better to use
> tango.

I have the seal of approval from the Canonical Design Team -- not gonna do
extra rounds beyond that now.

Best,

Bjoern

-- 
To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-design] Re: Minutes of the Design Hangout: 2015-10-07

[Bjoern Michaelsen]

Hi,

On Fri, Oct 09, 2015 at 10:13:43PM +0200, Jan Holesovsky wrote:
> * 'industrial' icon theme - keep or remove?
>  
> + https://gerrit.libreoffice.org/#/c/19149/
> + Human also depends on Industrial (Jay)
> + should that be actually depend on Tango? (Jay)
> + best to talk to Bjoern (Michaelsen) (Kendy)

Human has already been broken by tdf#93145 in LibreOffice 5.0.
There is no way Ubuntu will ship a huge set of fallback themes to make Human
complete again, thus we only ship themes with galaxy as fallback -- the
ultimate fallback.

For upcoming releases see lp#1506544:

 https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1506544

Note that does NOT mean we should immediately drop human. At least for
5.1/xenial it should be kept an transitional option.

Best,

Bjoern

-- 
To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-design] Re: Minutes of the Design Hangout: 2015-10-21

[Bjoern Michaelsen]

On Wed, Oct 28, 2015 at 06:54:47PM +0100, Jan Holesovsky wrote:
> * Present: Heiko, Jay, Kendy, Tomaz, Stuart
> 
> * UI changes integrated the last week:
> 
> + Enable auto-numbering by default reverted for now (Samuel)
> + First/last button in the Calc tab bar (Tomaž)
> + NotebookBar proof-of-concept pushed (Kendy)
> + alt-x support to math (Justin)
> + more 32px Breeze icons (Andreas)
> + Appearance -> Application Colors (Adolfo)
> + initial "Home" NotebookBar tab proof-of-concept (Samuel)
> + make sidebar toolboxs item order RTL sensitive (Bubli)

+ proper scrollwheel handling in TabBar/Sidebar (Bjoern)

-- 
To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-design] Re: [libreoffice-projects] Re: Workflow between dev, UX and l10n teams

[Bjoern Michaelsen]

Hi,

On Fri, Jan 30, 2015 at 10:06:36AM +0100, Lionel Elie Mamane wrote:
 Interestingly, doing a web search for pootle git synchronisation
 leads me to http://weblate.org/en/features/ :-)

Well, once we dont require to be self-hosted anymore,
https://translations.launchpad.net/ certainly would be an option too. However,
IMHO there are very good reasons to be self-hosted with translations.

Best,

Bjoern

-- 
To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-design] Re: Minutes of the Design Hangout: 2015-01-14

[Bjoern Michaelsen]

Hi Kendy,

On Fri, Jan 16, 2015 at 11:33:06AM +0100, Jan Holesovsky wrote:
 ...

Its great to see the awesome and consistent output of the design team here. I
wonder if you could share those on proje...@global.libreoffice.org too, so that
they help completing the broad overview of what is happening in the project 
along
with the ESC, QA, Infra, RelEng and Marketing announcements already there.

Best,

Bjoern

-- 
To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-design] Gran Canaria Hackfest Banner

[Bjoern Michaelsen]

Hi,

the GC Hackfest wiki page at:

 https://wiki.documentfoundation.org/Hackfest/GranCanaria2014

still misses a banner like:

 https://wiki.documentfoundation.org/File:HHHackfest2013.png

May I kindly ask for one to be adapted? Also, I wonder: Do we have a source
(ODG, whatever) for that somewhere on the wiki?

Best,

Bjoern

-- 
To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-design] Hackfest Flyers (URGENT)

[Bjoern Michaelsen]

Hi all,

Does the Design team have cycles to draft a Hackfest flyer by Monday latest?
_Anything_ is better that nothing, Eike and me try to get them distributed on
the local University campus. Note that having this is a good thing in general:
Once we have one, we can reuse it for later Hackfests and Sprints.

If there is no reply, I will try to make up something myself. To clarify: That
is a threat, not an offer. ;)

Best,

Bjoern

-- 
To unsubscribe e-mail to: design+unsubscr...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-design] Re: [Libreoffice-ux-advise] Fwd: Ubuntu Templates

[Bjoern Michaelsen]

Hi,

On Sat, Jun 09, 2012 at 04:47:26PM +0200, Alexander Wilms wrote:
 I tried to fix BrightBlue, to me it seems OK now. We still have some
 masterpages supplied by the community (cc0) and Mirek wanted to let
 the design list vote on them first, if there's still enough time to
 integrate them at all: http://ubuntuone.com/1rcQiE2v1xbJ0lWsIqWWzu

Uploaded. However for me BrightBlue is still broken, could you please have a
look at that again (Best: do a build from feature/masterpages and check
yourself) and remove it again, if its not fixable? If there are more
masterpages, please add them yourself, you have commit rights now -- no need to
do cumbersome errorprona nd annoying throwing around of zipped files etc.

Please just finalize feature/masterpages directly so that we can pull it into
libreoffice-3-6 before beta2(*). Thanks!

Best,

Bjoern
(*) Week 25: http://wiki.documentfoundation.org/ReleasePlan/3.6

-- 
Unsubscribe instructions: E-mail to design+h...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-design] Shiny, New EasyHacks

[Bjoern Michaelsen]

Hi all,

the shiny, new EasyHacks are there. Details at:
  http://sweetshark.livejournal.com/3997.html

Enjoy!

Best,

Bjoern  

-- 
https://launchpad.net/~bjoern-michaelsen



-- 
Unsubscribe instructions: E-mail to design+h...@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

[libreoffice-design] Git Artwork guide

[Bjoern Michaelsen]

Hi designers, Hi developers,

following the discussion on:

 https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/756895

I created a short tutorial for designers on how to get setup to
contribute artwork directly to the project at without a complete build:

 http://wiki.documentfoundation.org/Design/GitArtworkGuide

@Designers: Feel free to move it, beautify it and most of all: link to
it.
@Developers: Feel free to improve the guide, if I missed out some pits
that should be informed about.

Best Regards,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen



-- 
Unsubscribe instructions: E-mail to design+h...@libreoffice.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/www/design/
All messages sent to this list will be publicly archived and cannot be deleted

Re: [libreoffice-design] General relationship between coders and designers

[Bjoern Michaelsen]

Hi Bernhard,

On Tue, 15 Mar 2011 00:11:48 +0100
Bernhard Dippold bernh...@familie-dippold.at wrote:

  Please wait for the decision by the Design Team and we would be
  very glad if you could implement the resulting graphical
  approach by a  patch.
 
  Again - the code was merged day #1, then these 'fixes' were merged
  week #2, and we are not blocking on the advice of the design team.
  Clearly if something -really- upsets them we will back out the
  changes. Clearly if -everything- upsets the design team, and we
  find ourselves in some constant conflict - the design team's crying
  will start to become normal background noise, and have rather less
  impact. That is how relationships work right ?
 
 Not really:
 
 *If* the design team would be upset by any UI related development, it 
 would be worthwhile to find out the reason for such feelings.
 
 Just skipping them as normal background noise is far too easy and 
 indicates an attitude of ignorance for the broader community: This is 
 exactly what I called two classes...

No, that is not an attitude of ignorance for the broader community
and no two classes issue. If introduce a pink button in LibreOffice
and get flamed for it by any single person (coder or noncoder) a
few minutes later because he would prefer it in bright green, I would
likely ignore it (speaking of master, not a release branch obviously).
Otherwise I would not be making any progress at all or just be changing
the same colors over and over again.

If I get a link to a discussion on a mailing list a week later showing
consensus of the design team that bright green is indeed better than
pink in this case, I would change that. And I would expect the design
team to defend that decision and keep the discussion away from me from
that point on (that includes links to the discussion in the relevant
places).

Would I take the word of a trusted UXer without waiting a week? I
might, esp. if I get the feeling that I will end up changing the stuff
anyway or if there is a deadline (like a release branchoff) looming.

This is a lot different for most implementation issues, as consensus
there is often immediate. But this has to do with the topic and not
with classes.

 That's a topic that really needs interaction and decision making 
 *before* someone starts coding IMHO.

In most cases not. Most design choices are easily changed and tweaked
afterwards, but the hard part is enabling them to be tweakable at all.
Starting on the code will also show you what is easy to do and what is
hard -- an information you can only afford the luxury to ignore, if you
have unlimited resources.

 While this doesn't mean to hinder contributors from providing their 
 work, it is neither a reason to disqualify discussions leading to 
 consensus and decisions as long stream of complaints, allowing the 
 contributors to ignore it, just because they don't see it as useful
 input.

As long as there is no consensus, a coder can not derive _any_ valid
action from the discussion, so the only reasonable action is to ignore
it for his coding decisions. Any objections to that conclusion?

He might prepare his coding for likely outcomes, but that is guesswork.
He might also take part in the discussion, but that is independent from
his coding work (modulo his expertise on what is doable).

 So in a short term:
 
 * Every community member deserves the same respect for his
 contribution.
 
 * No contributor should be hindered to contribute in a way that
 brings LibreOffice forward.
 
 * No contributor should be told that his opinion is more valid than
 the recommendations of experts in their dedicated fields (but she is
 free to convince them).
 
 * If the contribution might interfere with general community goals or 
 agreed ways to reach these goals it might be handled like code 
 introducing bugs in other areas of the product. This will probably
 lead to modification of the contribution - in very seldom cases to
 rejection.

I agree mostly. However experts in their dedicated field is rather
vague and can be misused easily regardless of the field being coding
or UX. I would much prefer community consensus, which -- while
being equally vague -- at least does not introduce the exact two
classes (experts/nonexperts) issue described above.

Best Regards,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen

-- 
Unsubscribe instructions: E-mail to design+h...@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/design/
*** All posts to this list are publicly archived for eternity ***

Re: [libreoffice-design] Re: [PUSHED] fdo#31251 - Improve default page layout

[Bjoern Michaelsen]

Hi Thorsten, all,

On Thu, 10 Mar 2011 11:25:32 +0100
Thorsten Behrens t...@documentfoundation.org wrote:

 Bjoern Michaelsen wrote:
   For a developer interested in working on a certain topic it would
   be easier to get a final voting like
   The Design Team asks you to add a 8 px wide blurred shadow in
   grey transparency to all borders of the document. If the zoom
   factor reduces the space between two sheets to less than 16px, the
   overlapping areas of the shadow should be cut off. This should
   apply to every area of LibreOffice, where document borders are
   visible, namely Writer, Impress, Draw, XML forms [others not yet
   searched for].
  
  I am afraid you are very wrong there. It is not at all easier -- it
  is a lot harder -- and a lot less fun (the stuff that motivates
  volunteers).
 
 Speaking for myself here - I'd consider it *helpful* to get
 direction on those details. For me, it's not telling me how to code,
 but what to put into all those magic constant values needed for UI -
 I'd otherwise would need to trial-and-error those out, which is
 non-fun (for me).

Yes, of course working together is best. What bugged me here is that
the bug on fdo was reopened before there was actually a consensus on
how it can be done better. And the discussion about the bug was not
even linked there.

Keep in mind that closing a bug is a great boon for the developer --
dont take it away from him two days after he proudly closed it without a
clear message on what to do better.

 Besides, at least those bike-shed-color issues, are usually
 trivially fixable after-the-fact ... ;)

Exactly. Christoph applauded Sébastien for staying calm through all of
this. I have to agree and ask others to follow his example: If you
see some changes on master that you do not like: dont panic, create a
well founded argument and then come forward with it.

Best Regards,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen

-- 
Unsubscribe instructions: E-mail to design+h...@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/design/
*** All posts to this list are publicly archived for eternity ***

Re: [libreoffice-design] Re: [PUSHED] fdo#31251 - Improve default page layout

[Bjoern Michaelsen]

Hi Bernhard,

On Wed, 09 Mar 2011 22:16:48 +0100
Bernhard Dippold bernh...@familie-dippold.at wrote:

 Hi Björn, all,
 
 Bjoern Michaelsen schrieb:
  Hi Michael, Christoph, designers and developers
 
  [...]
 
  However, it is a such a common issue, that it even has a name
  Parkinson's Law of Triviality or colour of the bikeshed:
 
http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality
 
  So we should not be ashamed that it happens, only be prepared to
  handle it well. For developers this means that you cant make
  everybody happy and you should not dispair if not everybody loves
  your implementation on first sight.
 
 I agree with you that the design modification here is an example of 
 lower priority.

Priority is not the point. Please have a look at that wiki page. It is
more about that this (most small design issues) are something most
people have an opinion about, regardless of if they are designers,
developers, both or neither.

 But the way one of the main developer seems to disregard non-coding 
 community members is independent from this question.

No, I dont think that it is correct to put it that way: This is _not_ an
developer/nondeveloper issue. We currently have a very open model for
contributors on master and as I understand it, we want to keep it that
way to allow others to join in easily -- this is one of the
foundations of TDF/LO. This is not only the case for design issues, but
for all topics.
If somebody has something he thinks of as a great improvement, he can
commit that to master. If it breaks stuff, it will be reverted. If it
improves stuff, even if it does not make things perfect it stays in. If
there is a plan how to make things even better, that of course should
be done -- but you will not ever force volunteers to do it. It just
wont work (unless you pay them).
Nobody -- developer or nondeveloper -- should be able to block anybody
from doing a Good Thing(tm), just because he wants a Better Thing(tm).
And dont think that developers are so much more special than
nondevelopers: Even if I had twenty fulltime developers at my disposal
(in addition to myself), I would not get everything done I would love
to see changed. There is always more.
I see commits fly by every day that I would have done different. But
the only relevant question is: Is it at least better than before?.

From your other mail:
 For a developer interested in working on a certain topic it would be 
 easier to get a final voting like
 The Design Team asks you to add a 8 px wide blurred shadow in grey 
 transparency to all borders of the document. If the zoom factor
 reduces the space between two sheets to less than 16px, the
 overlapping areas of the shadow should be cut off. This should apply
 to every area of LibreOffice, where document borders are visible,
 namely Writer, Impress, Draw, XML forms [others not yet searched
 for].

I am afraid you are very wrong there. It is not at all easier -- it
is a lot harder -- and a lot less fun (the stuff that motivates
volunteers). To give you a car analogy (which are always broken, but
anyway), the statement above would be like telling a taxi driver not
where you want to go, but which route to take, when to changes lanes,
when to go faster or slower and when to change gears. You can do that
with a taxi driver, but he likely will not like it.
You better should not try it with a driver, who volunteered to get you
where you wanted to go. On the first ride, you should mostly just go
along with what he does (unless he drives you of a cliff). Before the
second ride, prepare to suggest improvements to him. If he is a
reasonable guy, he will listen to you -- esp. if you have a record of
being right about these things.

Best Regards,

Bjoern

-- 
https://launchpad.net/~bjoern-michaelsen

-- 
Unsubscribe instructions: E-mail to design+h...@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/design/
*** All posts to this list are publicly archived for eternity ***