Re: help desk vs bug tracker

[Martin Flöser]

Am 2018-10-29 19:22, schrieb David Edmundson:

I'm also wondering whether other KDE projects have the

 seem need as we have for Krita,

With my Plasma hat on:

Surprisingly, we don't get too many end user questions on bugzilla. I
think it tends to get loaded onto the distros instead.

We do get quite a few where the user thinks they have a bug but it's
an issue on their end but I don't think a helpdesk would solve them.


What I see in KWin quite often is: "foo doesn't work" or "KWin should do 
bar". And then you tell them how to enable the feature or that KWin 
already supports it. This is so common that I consider this as one of 
the huge pain point in bugzilla. For me that falls under "user support" 
and I think a helpdesk system could improve the situation (Obviously it 
requires users going there and if a user knows something like "KWin" 
exists and can report a bug against it it's a lost case - a user 
shouldn't know KWin exists).


Cheers
Martin

Re: Discourse

[Eike Hein]

On 10/29/18 1:31 PM, Jonathan Riddell wrote:
> More coverage on last week's LWN
> https://lwn.net/Articles/768483/
> 
> Discussing it in person it was pointed out that we do already use
> Phabricator Workboards for much discussion and it might well overlap
> there, although I don't think that would be any more of an issue than
> mailing lists overlapping.

When I read that LWN article some time ago, it struck me that the Python
and Fedora communities are very different from ours in that they were
still doing most of their development discussions on mailing lists,
whereas we've migrated nearly all of the ones we don't have in chats
anyway to Phabricator. That means the need for Discourse isn't quite the
same, and it also does mean to me that Phabricator and Discourse might
end up stepping on each others' toes and cause more fragementation. I
prefer a single thing over two things, I guess.

On the users forums replacement angle I can't really comment.



> Jonathan

Cheers,
Eike

Re: help desk vs bug tracker

[Scott Petrovic]

I think "bot" isn't really the best term to describe what a Q site is --
or what AskBot does. When I think of "bot", I think of some type of AI that
tries to chat with people or interacts with them as if they are a person. I
am pretty sure Askbot doesn't work like that. It is closer to something
like StackOverflow.

This issue might only pertain to Krita, but this is how it currently tries
to separate issues with artists

   - bug tracker tracking bugs and wishlist items
   - forum that is a generic bucket that has a lot of things (discussion
   about new artwork, people wanting new features, people asking about bugs or
   issues, people wanting to be involved, general discussion)
   - chatroom (IRC) real-time support if the developers are at their
   computer


I feel like this Q site's job is more focused on answering very specific
questions that might be asked frequently (and developers can look up
quickly and reference). Right now with the forum and Krita, there are quite
a few questions that are asked over and over which get a bit tiring. I
imagine some people aren't even searching because of how the forum is set
up. Searches also bring back discussions about artwork, feature requests,
or other discussions not related to the question. The forum search also
searches across all KDE products, which can be a bit confusing at times for
people that don't know that searching the forum will search across all KDE
products, not just Krita.

Scott Petrovic



On Tue, Oct 30, 2018 at 3:23 AM Hans "totte" Tovetjärn <
to...@chakralinux.org> wrote:

> On 2018-10-30 08:55, Laszlo Papp wrote:
> > On Tue, Oct 30, 2018 at 7:33 AM Boudewijn Rempt 
> > wrote:
> >
> >> On maandag 29 oktober 2018 19:25:44 CET Andy Betts wrote:
> >>
> >>>
> >>> Maybe one thing that is hard to deal with is the sheer email
> >> distribution
> >>> where you can’t seem to be able to route people’s questions or
> >> requests to
> >>> the right audience. We also get endless threads that you can’t
> >> seem to be
> >>> able to unsubscribe from. Would some of these tools be able to do
> >> that?
> >>
> >> The nice thing about askbot is that it actually combines asking and
> >> searching:
> >> so typing your question already starts showing up possible answers.
> >> That
> >> should go a long way to solving the repeated questions we get a lot
> >> of.
> >
> > Isn't google supposed to do that? You type the question and you get
> > the answer in a result.
> >
> > I personally do not like these bot support sites for services as it
> > makes the interaction impersonal. I also do not trust bots not making
> > big mistakes, potentially misleading me.
>
> How is it making the interaction "impersonal"? The software simply shows
> potentially related questions previously asked based on the subject
> lines. Q software also encourages asking direct questions and
> getting direct answers, with a layout that makes it easier for others
> with the same issue to navigate, as opposed to the sometimes
> too-long-to-read paginated mess on more classical discussion boards.
>
> --
> Best regards,
> Hans "totte" Tovetjärn
> to...@chakralinux.org
> 0xEB5A95EC99421F98
>

Re: Discourse

[Michael Reeves]

On Tue, Oct 30, 2018, 6:50 AM Paul Adams  wrote:

> On Tue, 30 Oct 2018 at 11:42, Ben Cooksley  wrote:
> > If you're running 10,000+ microservice instances, then you can have
> > the teams of people needed to maintain the necessary overhead
>
> This is true. Also not your original point: you claimed that Docker
> containers were generally unsuitable for production
> The overhead is generally not that huge: you build, sign and upload
> your images to registry you run. This is no different than when you
> build, sign and upload your custom-built distro packages.
>
> Yes, running something like Openstack cause some additional overhead.
>
> > We delegate management of sites to people who look after them (where
> > it makes sense) as it helps people get things done.
> > They are essentially the "admin" of that specific site/service, but
> > won't have root on the actual server that runs it.
>
> Good approach. It is by no means incompatible with running services in
> a container.
> You can give specific system users membership of a docker group,
> allowing them to start/stop/deploy etc. You then control which
> containers the user is actually allowed to manipulate in registry
> config.
>
> Perhaps I am missing something?
>

Care would have to taken to insure such users can only use specific pre
defined option sets. Otherwise the ability to run docker is equivalent to
root access to the real file system via. --mount or --volumes. Probably
other routes as well. Not hard to mitigate with the right setup.

>
> --
> Paul J. Adams
>   PhD MIEEE MBCS CITP
>
> GPG: 07DD 0812 Paul James Adams
>

Re: Discourse

[Lays Rodrigues]

I do think that we should consider to move to discourse.
One thing that I've learned with the agile method is to discover the 'pain'
of my user and try to cure it.
What i see from this thread is the 'pain' of maintaining this kind of
infrastructure, that I think that using
tools of automations like Ansible or Kubernetes for the orquestration and
management of containers would
aliviate that kind of pain.
But I could be wrong, since I don't know any idea of the work that the kde
sysadmins have.
I love automation and how that makes my life easier at work.
I agree over Paul Adams comments, and I think that if we want to go forward
on this, we need to study it,
find the poins of 'pain' and come up with solutions that can be good for
everyone.

For me, all the movements that want to bring KDE to a modern web are
valid... to be studied and maybe implemented.

On Tue, Oct 30, 2018 at 7:50 AM Paul Adams  wrote:

> On Tue, 30 Oct 2018 at 11:42, Ben Cooksley  wrote:
> > If you're running 10,000+ microservice instances, then you can have
> > the teams of people needed to maintain the necessary overhead
>
> This is true. Also not your original point: you claimed that Docker
> containers were generally unsuitable for production
> The overhead is generally not that huge: you build, sign and upload
> your images to registry you run. This is no different than when you
> build, sign and upload your custom-built distro packages.
>
> Yes, running something like Openstack cause some additional overhead.
>
> > We delegate management of sites to people who look after them (where
> > it makes sense) as it helps people get things done.
> > They are essentially the "admin" of that specific site/service, but
> > won't have root on the actual server that runs it.
>
> Good approach. It is by no means incompatible with running services in
> a container.
> You can give specific system users membership of a docker group,
> allowing them to start/stop/deploy etc. You then control which
> containers the user is actually allowed to manipulate in registry
> config.
>
> Perhaps I am missing something?
>
> --
> Paul J. Adams
>   PhD MIEEE MBCS CITP
>
> GPG: 07DD 0812 Paul James Adams
>


-- 

*Lays Rodrigues*

*KDE*

*Atelier - atelier.kde.org *

*Fundraising WG*
*http://lays.space *
*Telegram: @lays147*

Re: Discourse

[Paul Adams]

On Tue, 30 Oct 2018 at 11:42, Ben Cooksley  wrote:
> If you're running 10,000+ microservice instances, then you can have
> the teams of people needed to maintain the necessary overhead

This is true. Also not your original point: you claimed that Docker
containers were generally unsuitable for production
The overhead is generally not that huge: you build, sign and upload
your images to registry you run. This is no different than when you
build, sign and upload your custom-built distro packages.

Yes, running something like Openstack cause some additional overhead.

> We delegate management of sites to people who look after them (where
> it makes sense) as it helps people get things done.
> They are essentially the "admin" of that specific site/service, but
> won't have root on the actual server that runs it.

Good approach. It is by no means incompatible with running services in
a container.
You can give specific system users membership of a docker group,
allowing them to start/stop/deploy etc. You then control which
containers the user is actually allowed to manipulate in registry
config.

Perhaps I am missing something?

-- 
Paul J. Adams
  PhD MIEEE MBCS CITP

GPG: 07DD 0812 Paul James Adams

Re: Discourse

[Ben Cooksley]

On Tue, Oct 30, 2018 at 10:59 PM Paul Adams  wrote:
>
> On Tue, 30 Oct 2018 at 07:28, Ben Cooksley  wrote:
> > Sorry, Docker might be a wonderful way to test applications, but it's
> > totally unsuitable for production workloads.
>
> That's a bold claim. At Zalando we have 10,000s of microservices in
> production and each one of them is running inside a Docker container.
> this has been our deployment vector for years
>
> We are far from alone in this.

If you're running 10,000+ microservice instances, then you can have
the teams of people needed to maintain the necessary overhead, which
you go into below...

We're completely different in scale - there wouldn't even be 10,000
processes (or even 5,000 to be honest) across all of the KDE servers
combined.
At our level of scale, having to run all the instrumentation layers
you go into below actually creates more work than the benefit to be
gained from it.

>
> > First, the contents of that Docker image can be confirmed how exactly?
>
> You build the image yourself, sign it and upload to your own private registry.
>
> > Second, it's impossible for Sysadmin to delegate management of a
> > Docker container to anyone.
>
> There are third party tools to support this and Docker itself supports
> delegation of signing and deployment.
> Each team at Zalando has full autonomy to start/stop/update/deploy and
> reassign their running services (and therefore the container).
>
> This is handled by an open source tech we have released called STUPS:
> https://stups.io/
>
> Sadly, this is AWS-centric, but I am sure there are other solutions
> that solve the same problem. Openstack?

So to make all of this work (securely), I count:

1) A private Docker registry
2) An orchestration system to manage your Docker cluster, complete
with access control around who can do what
3) A system to build and sign the images you work with, and
corresponding setup on your workers to validate those keys on your
images.

That's quite a bit of overhead.

Openstack itself is quite a heavy bit of software too.

>
> > This means if anything goes wrong with it a Sysadmin would have to be
> > the one to take a look
>
> Genuine comment:
> Unless you are doing devops, when *anything* goes wrong I would expect
> the sysadmin to be the first to react.
> If you /are/ doing devops, then of course it is the deploying team who reacts.

We delegate management of sites to people who look after them (where
it makes sense) as it helps people get things done.
They are essentially the "admin" of that specific site/service, but
won't have root on the actual server that runs it.

Regards,
Ben

>
> --
> Paul J. Adams
>   PhD MIEEE MBCS CITP
>
> GPG: 07DD 0812 Paul James Adams

Re: Discourse

[Harald Sitter]

On Tue, Oct 30, 2018 at 8:38 AM Boudewijn Rempt  wrote:
>
> On maandag 29 oktober 2018 19:31:54 CET Jonathan Riddell wrote:
> > Discourse is modern forum and mailing list software.  Examples at
> > https://discussion.fedoraproject.org/ or https://discourse.ubuntu.com/
> >
> > I went to a talk at the Embedded Linux Summit about how Fedora moved to use
> > Discourse.  Similar to the discussion of moving away from IRC we had last
> > year I see people moving away from mailing lists and new contributors not
> > wanting to get into them.  Our KDE Forums also look quite old school.  In
> > Fedora they moved to Discourse and mailing lists and forums and saw a
> > marked increase in engagement.
> >
> > I think KDE should consider moving away from mailman and onto Discourse and
> > at the same time forum.kde.org could move to this more modern software. It
> > might also help cover Boud's use case of a user support method for people
> > with queries before the report a bug.
>
> I don't think it's really comparable. Discourse might be a good alternative
> for mailing lists and forums, where people have discussions, but it doesn't
> look like a good alternative for a solution where people who have a problem,
> ask about it, and get a (semi-automatic) answer because it's been asked a
> hundred times before. It's the latter we really need :-)

Yeah, I don't think it's really suitable for a help desk. Specifically
since for a help desk you want the software to assist you in seeing
unresolved and unanswered tickets and easily fire canned responses, so
it very much needs special software.

HS

Re: Discourse

[Christian Loosli]

Hi all, 

from what I get from the documentation, discourse has a mailing list mode 
which can, from a end user point of view, be used the same as a mailing list. 
As in: in a mail client, without additional config that would not be needed 
with a ML as well. 

So assuming we have

1) Sysadmins who are willing to install, configure and host this
2) A migration path for
2a) existing conversations
2b) our mailing lists and, more important, whether public or private and who 
should be subscribed 

I don't see why not. If it doesn't have the mailing list mode or if it doesn't 
work as I suspect it to, I'd be between very hesitant and against it, because 
I most definitely prefer my e-mail client over yet another crappy web app that 
is placed in a view and sold as client. 
If we don't have the migration path I'd be hesitant as well, unless we have a 
decent solution to 

- have continuity and not a sudden break / change, as there are ongoing 
conversations  (and running both in parallel is very bad) 
- make sure we have the manpower and plan to migrate lists and their 
permissions over 


Kind regards, 

Christian

PS: on the side discussion of docker: I am not against docker, we use it in 
(soon to be) production, we orchestrate it with OpenShift. But I do have to 
say that it is something entirely different and thus needs people willing and 
able to manage it, and this also needs planning on how to integrate it in 
already existing infrastructure, also security wise. So if we don't have infra 
people already comfortable with docker, do plan some extra time to build that 
up.

PPS: I am still not terribly fond of the argumentation "we have to move to 
$some_fancy_new_shit_software or otherwise people will leave us". If people 
are contributing to / be with KDE just because of our choice of infra 
software, we are most definitely doing something wrong. But I already went on 
about that during the anti-IRC discussion.

Re: Discourse

[Luca Beltrame]

Il giorno Tue, 30 Oct 2018 08:38:28 +0100
Boudewijn Rempt  ha
scritto:

> As for the forum, it would be good to replace that with something
> more modern. We get a lot of traffic on the forums, People don't

I don't want to sound overly negative, but that's a common feeling also
for those who handle(d) the forums. The problems are:

1. Keeping the old posts
2. Ensuring the alternative (or the upgraded variant, e.g. to the
latest phpBB) is maintained

Upgrades have been considered but there's quite a lot of custom code
there and no one in the staff actually can handle PHP that well. Also
(like I said elsewhere) someone needs to have both time and motivation
for it.


pgpzMQrXTUr01.pgp
Description: Firma digitale OpenPGP

Re: Discourse

[Paul Adams]

On Tue, 30 Oct 2018 at 07:28, Ben Cooksley  wrote:
> Sorry, Docker might be a wonderful way to test applications, but it's
> totally unsuitable for production workloads.

That's a bold claim. At Zalando we have 10,000s of microservices in
production and each one of them is running inside a Docker container.
this has been our deployment vector for years

We are far from alone in this.

> First, the contents of that Docker image can be confirmed how exactly?

You build the image yourself, sign it and upload to your own private registry.

> Second, it's impossible for Sysadmin to delegate management of a
> Docker container to anyone.

There are third party tools to support this and Docker itself supports
delegation of signing and deployment.
Each team at Zalando has full autonomy to start/stop/update/deploy and
reassign their running services (and therefore the container).

This is handled by an open source tech we have released called STUPS:
https://stups.io/

Sadly, this is AWS-centric, but I am sure there are other solutions
that solve the same problem. Openstack?

> This means if anything goes wrong with it a Sysadmin would have to be
> the one to take a look

Genuine comment:
Unless you are doing devops, when *anything* goes wrong I would expect
the sysadmin to be the first to react.
If you /are/ doing devops, then of course it is the deploying team who reacts.

-- 
Paul J. Adams
  PhD MIEEE MBCS CITP

GPG: 07DD 0812 Paul James Adams

Re: Discourse

[Harald Sitter]

On Mon, Oct 29, 2018 at 7:32 PM Jonathan Riddell  wrote:
>
>
> Discourse is modern forum and mailing list software.  Examples at 
> https://discussion.fedoraproject.org/ or https://discourse.ubuntu.com/
>
> I went to a talk at the Embedded Linux Summit about how Fedora moved to use 
> Discourse.  Similar to the discussion of moving away from IRC we had last 
> year I see people moving away from mailing lists and new contributors not 
> wanting to get into them.  Our KDE Forums also look quite old school.  In 
> Fedora they moved to Discourse and mailing lists and forums and saw a marked 
> increase in engagement.
>
> I think KDE should consider moving away from mailman and onto Discourse and 
> at the same time forum.kde.org could move to this more modern software. It 
> might also help cover Boud's use case of a user support method for people 
> with queries before the report a bug.

I love using discourse and am totally in favor of using it. It has so
much more enjoyable UX than just about any other forum software I've
ever had to use. And the ability to bridge the divide between what
developers use (email) and what users use (forum) is a dream come
true!

HS

Re: Discourse

[Harald Sitter]

On Tue, Oct 30, 2018 at 7:28 AM Ben Cooksley  wrote:
> thanks to Docker's lack of user namespaces

Docker has user namespacing. At blue systems we've been using it since
September 2016

https://docs.docker.com/engine/security/userns-remap/

HS

Re: Discourse

[totte]

On 2018-10-30 08:38, Boudewijn Rempt wrote:

On maandag 29 oktober 2018 19:31:54 CET Jonathan Riddell wrote:

Discourse is modern forum and mailing list software.  Examples at
https://discussion.fedoraproject.org/ or https://discourse.ubuntu.com/

I went to a talk at the Embedded Linux Summit about how Fedora moved 
to use
Discourse.  Similar to the discussion of moving away from IRC we had 
last
year I see people moving away from mailing lists and new contributors 
not
wanting to get into them.  Our KDE Forums also look quite old school.  
In

Fedora they moved to Discourse and mailing lists and forums and saw a
marked increase in engagement.

I think KDE should consider moving away from mailman and onto 
Discourse and
at the same time forum.kde.org could move to this more modern 
software. It
might also help cover Boud's use case of a user support method for 
people

with queries before the report a bug.


I don't think it's really comparable. Discourse might be a good 
alternative
for mailing lists and forums, where people have discussions, but it 
doesn't
look like a good alternative for a solution where people who have a 
problem,
ask about it, and get a (semi-automatic) answer because it's been asked 
a

hundred times before. It's the latter we really need :-)


If you need *both* discussion and Q support, there is this 
plugin for Discourse: 
https://meta.discourse.org/t/discourse-solved-accepted-answer-plugin/30155. 
It doesn't make it as good as I find StackExchange or AskBot, but it is 
something.



But when it comes to mailing lists and forums...

kimages...@kde.org basically only gets used for announcements. All 
discussions
happen on Phabricator or on IRC. Almost nobody with a question 
subscribes to
the mailing list. The only thing that gets less used than the mailing 
list is

the FAQ.


At a glance, the FAQ is looking good in terms of legibility: 
https://docs.krita.org/en/KritaFAQ.html, how have you come to the 
conclusion that it is so unpopular?


We also do get user support questions on IRC, through the web 
interface, but
it's clear that it confuses people horribly. They come, ask and leave, 
or
don't know what to do once they're in the channel. Much as it pains me, 
for

user support, IRC is the wrong tool. It's still find for project
collaboration, though.

As for the forum, it would be good to replace that with something more 
modern.
We get a lot of traffic on the forums, People don't understand the 
layout of
the forums, but because there's only an RSS feed, no email integration, 
I miss
a lot of questions, and it's often very unclear what the current 
questions
are. And the process of registering and logging in to the forum 
confuses

people a lot, too.


Can you not subscribe to https://forum.kde.org/viewforum.php?f=136 to 
get e-mail notifications? Is it the identity.kde.org feature that makes 
registering difficult? Could this be alleviated by allowing for OAuth2?


--
Best regards,
Hans "totte" Tovetjärn
to...@chakralinux.org
0xEB5A95EC99421F98

Re: Discourse

[Ben Cooksley]

On Tue, Oct 30, 2018 at 8:38 PM Boudewijn Rempt  wrote:
>
> On maandag 29 oktober 2018 19:31:54 CET Jonathan Riddell wrote:
> > Discourse is modern forum and mailing list software.  Examples at
> > https://discussion.fedoraproject.org/ or https://discourse.ubuntu.com/
> >
> > I went to a talk at the Embedded Linux Summit about how Fedora moved to use
> > Discourse.  Similar to the discussion of moving away from IRC we had last
> > year I see people moving away from mailing lists and new contributors not
> > wanting to get into them.  Our KDE Forums also look quite old school.  In
> > Fedora they moved to Discourse and mailing lists and forums and saw a
> > marked increase in engagement.
> >
> > I think KDE should consider moving away from mailman and onto Discourse and
> > at the same time forum.kde.org could move to this more modern software. It
> > might also help cover Boud's use case of a user support method for people
> > with queries before the report a bug.
>
> I don't think it's really comparable. Discourse might be a good alternative
> for mailing lists and forums, where people have discussions, but it doesn't
> look like a good alternative for a solution where people who have a problem,
> ask about it, and get a (semi-automatic) answer because it's been asked a
> hundred times before. It's the latter we really need :-)
>
> But when it comes to mailing lists and forums...
>
> kimages...@kde.org basically only gets used for announcements. All discussions
> happen on Phabricator or on IRC. Almost nobody with a question subscribes to
> the mailing list. The only thing that gets less used than the mailing list is
> the FAQ.
>
> We also do get user support questions on IRC, through the web interface, but
> it's clear that it confuses people horribly. They come, ask and leave, or
> don't know what to do once they're in the channel. Much as it pains me, for
> user support, IRC is the wrong tool. It's still find for project
> collaboration, though.
>
> As for the forum, it would be good to replace that with something more modern.
> We get a lot of traffic on the forums, People don't understand the layout of
> the forums, but because there's only an RSS feed, no email integration, I miss
> a lot of questions, and it's often very unclear what the current questions
> are. And the process of registering and logging in to the forum confuses
> people a lot, too.

The login and registration experience is something that is being worked on.

Regards,
Ben

>
> --
> https://www.krita.org

Re: help desk vs bug tracker

[totte]

On 2018-10-30 08:55, Laszlo Papp wrote:

On Tue, Oct 30, 2018 at 7:33 AM Boudewijn Rempt 
wrote:


On maandag 29 oktober 2018 19:25:44 CET Andy Betts wrote:



Maybe one thing that is hard to deal with is the sheer email

distribution

where you can’t seem to be able to route people’s questions or

requests to

the right audience. We also get endless threads that you can’t

seem to be

able to unsubscribe from. Would some of these tools be able to do

that?

The nice thing about askbot is that it actually combines asking and
searching:
so typing your question already starts showing up possible answers.
That
should go a long way to solving the repeated questions we get a lot
of.


Isn't google supposed to do that? You type the question and you get
the answer in a result.

I personally do not like these bot support sites for services as it
makes the interaction impersonal. I also do not trust bots not making
big mistakes, potentially misleading me.


How is it making the interaction "impersonal"? The software simply shows 
potentially related questions previously asked based on the subject 
lines. Q software also encourages asking direct questions and 
getting direct answers, with a layout that makes it easier for others 
with the same issue to navigate, as opposed to the sometimes 
too-long-to-read paginated mess on more classical discussion boards.


--
Best regards,
Hans "totte" Tovetjärn
to...@chakralinux.org
0xEB5A95EC99421F98

Re: help desk vs bug tracker

[Boudewijn Rempt]

On dinsdag 30 oktober 2018 08:55:03 CET Laszlo Papp wrote:

> Isn't google supposed to do that? You type the question and you get the
> answer in a result.

No, google isn't supposed to do that, and doesn't do that -- google is no 
alternative for user support.

> I personally do not like these bot support sites for services as it makes
> the interaction impersonal. I also do not trust bots not making big
> mistakes, potentially misleading me.

I think you're overestimating the automation, askbot doesn't do scripted 
question and answer (though that would be very useful as well) -- but in the 
end, the problem isn't that a potential ask.krita.org might give a misleading 
answer, but that the user doesn't get an answer at all because too much of the 
support load falls on too few shoulders.


-- 
https://www.krita.org

signature.asc
Description: This is a digitally signed message part.

Re: help desk vs bug tracker

[Laszlo Papp]

On Tue, Oct 30, 2018 at 7:33 AM Boudewijn Rempt  wrote:

> On maandag 29 oktober 2018 19:25:44 CET Andy Betts wrote:
>
> >
> > Maybe one thing that is hard to deal with is the sheer email distribution
> > where you can’t seem to be able to route people’s questions or requests
> to
> > the right audience. We also get endless threads that you can’t seem to be
> > able to unsubscribe from. Would some of these tools be able to do that?
>
> The nice thing about askbot is that it actually combines asking and
> searching:
> so typing your question already starts showing up possible answers. That
> should go a long way to solving the repeated questions we get a lot of.
>

Isn't google supposed to do that? You type the question and you get the
answer in a result.

I personally do not like these bot support sites for services as it makes
the interaction impersonal. I also do not trust bots not making big
mistakes, potentially misleading me.


>
> --
> https://www.krita.org

Re: help desk vs bug tracker

[Boudewijn Rempt]

On maandag 29 oktober 2018 19:22:52 CET David Edmundson wrote:
> >I'm also wondering whether other KDE projects have the
> 
> seem need as we have for Krita,
> 
> With my Plasma hat on:
> 
> Surprisingly, we don't get too many end user questions on bugzilla. I think
> it tends to get loaded onto the distros instead.
> 
> We do get quite a few where the user thinks they have a bug but it's an
> issue on their end but I don't think a helpdesk would solve them.

Yes, I was suspecting that Krita might be an outlier here. 

-- 
https://www.krita.org

signature.asc
Description: This is a digitally signed message part.

Re: Discourse

[Boudewijn Rempt]

On maandag 29 oktober 2018 19:31:54 CET Jonathan Riddell wrote:
> Discourse is modern forum and mailing list software.  Examples at
> https://discussion.fedoraproject.org/ or https://discourse.ubuntu.com/
> 
> I went to a talk at the Embedded Linux Summit about how Fedora moved to use
> Discourse.  Similar to the discussion of moving away from IRC we had last
> year I see people moving away from mailing lists and new contributors not
> wanting to get into them.  Our KDE Forums also look quite old school.  In
> Fedora they moved to Discourse and mailing lists and forums and saw a
> marked increase in engagement.
> 
> I think KDE should consider moving away from mailman and onto Discourse and
> at the same time forum.kde.org could move to this more modern software. It
> might also help cover Boud's use case of a user support method for people
> with queries before the report a bug.

I don't think it's really comparable. Discourse might be a good alternative 
for mailing lists and forums, where people have discussions, but it doesn't 
look like a good alternative for a solution where people who have a problem, 
ask about it, and get a (semi-automatic) answer because it's been asked a 
hundred times before. It's the latter we really need :-)

But when it comes to mailing lists and forums...

kimages...@kde.org basically only gets used for announcements. All discussions 
happen on Phabricator or on IRC. Almost nobody with a question subscribes to 
the mailing list. The only thing that gets less used than the mailing list is 
the FAQ.

We also do get user support questions on IRC, through the web interface, but 
it's clear that it confuses people horribly. They come, ask and leave, or 
don't know what to do once they're in the channel. Much as it pains me, for 
user support, IRC is the wrong tool. It's still find for project 
collaboration, though.

As for the forum, it would be good to replace that with something more modern. 
We get a lot of traffic on the forums, People don't understand the layout of 
the forums, but because there's only an RSS feed, no email integration, I miss 
a lot of questions, and it's often very unclear what the current questions 
are. And the process of registering and logging in to the forum confuses 
people a lot, too.

-- 
https://www.krita.org

signature.asc
Description: This is a digitally signed message part.

Re: help desk vs bug tracker

[Boudewijn Rempt]

On maandag 29 oktober 2018 19:25:44 CET Andy Betts wrote:

> 
> Maybe one thing that is hard to deal with is the sheer email distribution
> where you can’t seem to be able to route people’s questions or requests to
> the right audience. We also get endless threads that you can’t seem to be
> able to unsubscribe from. Would some of these tools be able to do that?

The nice thing about askbot is that it actually combines asking and searching: 
so typing your question already starts showing up possible answers. That 
should go a long way to solving the repeated questions we get a lot of. 

-- 
https://www.krita.org

signature.asc
Description: This is a digitally signed message part.

Re: Discourse

[Paul Brown]

Hello,

Although my experience maintaining a full-fledged Discourse deployment is nil 
(so I can't speak to that side of the discussion with any authority), I did 
install and research Discourse for an experiment with Hispalinux a couple of 
years ago.

From a users' point of view, the Discourse interface is usable (as in it 
complies with most rules of usability), looks good and makes following and 
mining threads easy. Furthermore, as Rubén points out, Discourse provides a 
way for users who prefer mailing lists to participate without having to change 
their habits. Discourse also helps to certain degree with self-regulation: all 
parties, admins and end-users, can collaborate in curbing spam and trolls.

I understand and appreciate the technical issues, but, fwiw, a change that 
would help attract more people without having to use yet another proprietary 
medium gets a +1 from me.

Now, if we could just move on from Telegram without taking a step back...

Cheers

Paul
-- 
Promotion & Communication

www: http://kde.org
Mastodon: https://mastodon.technology/@kde
Facebook: https://www.facebook.com/kde/
Twitter: https://twitter.com/kdecommunity



signature.asc
Description: This is a digitally signed message part.

Re: Discourse

[Ben Cooksley]

On Tue, Oct 30, 2018 at 11:28 AM Jonathan Riddell  wrote:
>
> On Mon, 29 Oct 2018 at 20:56, Luca Beltrame  wrote:
> > - As far as I remember, they *only* supported deployment with Docker.
> >   This is is IMO a terrible and black-magic approach
>
> Seems like a perfectly sensible and modern way to deploy.  You can log
> into the running container fine and twiddle as needed.

Sorry, Docker might be a wonderful way to test applications, but it's
totally unsuitable for production workloads.

First, the contents of that Docker image can be confirmed how exactly?
While the Dockerfile might be available for us to inspect somewhere,
is it possible for us to verify that what is supposed to be in the
*binary* image (which isn't signed) is what the build log for that
Dockerfile actually produced?

Second, it's impossible for Sysadmin to delegate management of a
Docker container to anyone. Having access to Docker's management
socket grants effective root rights over the host to the people with
access to that, thanks to Docker's lack of user namespaces, ability to
launch privileged containers (which have no limits on their access to
the physical host) and have arbitrary folders on the system (including
the whole root filesystem should one want to) mounted as volumes into
a container. Escalation to root on the system would be as simple as
1-2-3.

This means if anything goes wrong with it a Sysadmin would have to be
the one to take a look, investigate and resolve the issue. For
non-containers we can fully delegate this (even in the case of Ruby
apps - Passenger is awesome for auto-scaling and letting people
control this sort of stuff) so this would be a substantial step
backwards and would increase the barrier to entry and pressure on the
Sysadmin team.

Virtually all of our servers run multiple workloads, which means the
second point is a *hard* deal breaker for us. Case in point, the
current server for the Forum (known as Silk) also hosts amongst other
things: the Dot, Akademy site, Krita.org, Techbase, Userbase, our
CiviCRM instance and our website statistics collection system
(Matomo).

Additionally, we use LXC ( https://linuxcontainers.org/ ) for running
all of the workloads on our primary servers. Running Docker within LXC
requires relaxing the security constraints that LXC containers have
imposed on them under normal conditions, making them inherently less
secure, which sounds like a bad idea to me.

>
> > - It uses (used to use?) PostgreSQL as database, for which Sysadmin
> >   isn't really keen on using unless absolutely necessary
>
> Shrug, personal taste.

Sorry, but that's not a case of personal taste. Virtually all of our
servers, with few exceptions, run MySQL / MariaDB and I don't think
it's a good idea to run two database servers on the same system (more
maintenance, two things to keep backed up, plus we don't have as much
experience for problems with Postgres when compared with MySQL)

>
> > - The UX is not as best as it looks, hijacks stuff like the back button
> >   on the browser and what not
>
> Shrug, personal taste.
>
> > - The "app" on mobile is a joke, basically a web view of the mobile page
>
> I'm told the app works fine web view or no, doesn't seem a reason to
> dislike an app.
>
> > > I think KDE should consider moving away from mailman and onto
> >
> > Does Discourse have a mail interface to avoid breaking user workflows?
> > How should a migration be handled? Don't forget we'll lose distributed
> > archiving of the mailing lists as well (very useful).
>
> It certainly notifies by e-mail, I've not yet worked out how it treats
> incoming e-mail.
>
> It has import filters for mailman and maybe phpBB but also if we ever
> got to a point where we dropped the current systems entirely they can
> just be turned read only and continue to be used as archives.
>
> > Also, don't forget that "should", to quote a seminar I was at recently,
> > should become "I/we/they will". If no one is willing to put support
> > with the (aged! I'm not saying it's perfect) forum infrastructure why
> > do you think one would put up with the new?
>
> Of course it would need someone to do the work, but it would mean
> replacing two systems with one.
>
> Jonathan

Cheers,
Ben