Communications 2.0

[Jasper Backer]

On 02-05-16 12:56, Tim wrote:
> Many people over recent times have complained about our communications channels. It seems the established staple diet of IRC and Mailing lists,
> that just about every established FOSS teams use doesnt work so well, particularly for the newcomers in our community. I am hoping to create a
> UOS[1] session to discuss some of these things, but lets get the discussion started before that.
How come other teams can use the traditional methods just fine and we don't?
>
> Apparently every time we raise this stuff on the list, it gets taken way off topic by trolls and their politics. So let me start with a little
> warning, if anyone tries to derail this thread with proprietry vs FOSS politics, I won’t hesitate to ban you from the email list. This is about
> finding solutions that work for improving communications for our users and core teams.
>
> The current situation is basically:
>
> IRC – Real time messaging, it is great in that everyone is there (most ubuntu/GNOME/debian developers etc), but it can be hard for people that
> aren’t used to it, timezones are a challenge, particularily when you cant stay connect 24/7. Also so far no one outside of our development/qa
> areas has really embraced IRC
IMO (unfortunately) IRC is still a main communication tool and somewhat 
directly related with being in these (OS/dev/test/etc) circles.
>
> Mailing Lists – Generally work well if you constantly follow the messages, many complain about it being hard to catch up with past discussions,
> which I guess is particularily true if you use the web interface.
However, again, this is "classic" to any distro - How come we can't 
utilize this properly?
>
> Launchpad – Bug tracking, it handles tracking individual bugs really well, but the shear volume of bugs makes it hard to track/find specific
> bugs. We are not about to move away from that, but we could find better ways to tag/track Ubuntu GNOME specific bugs in a centralised location.
>
> Wiki – has lots of useful information, but many find it hard to navigate. Also generally most people are too scared to try and edit it, since
> MoinMoin markup is a bit of a learning curve.
IMO the wiki is a huge non-organized mess. Same would go for the website 
which is unprofessional and unclear. Luckily the distro speaks for 
itself, but the website and wiki do no good as it lowers the quality 
perception on the product.


I think we need a better seperation of information between the wiki and the website. The wiki has loads of useful information on it, but
newcomers find it hard to navigate. The website is really meant to be the portal for new users, but largely just links to the wiki. Of course we
will try improve this with the new website, once it arrives, but either way the wiki could use some improvements. I did a little experiment
today pretending to be a new user, and think I got up to about 10 links without my questions answered (simply what is involved in testing Ubuntu
GNOME)!

Even I gave up to for example try and translate the release notes as the 
path is super unclear. For example for Fedora I wanted to change some 
Dutch translations and literally was able to do so in an hour with the 
translation being online the next day.
>
> I think some sort of central hub for planning would be useful, maybe that would just be a page that aggregates information from the various
> existing channels or an entire new platform. We are very much lacking in the collaborative documentation section and in particular that is
> discoverable. Blueprints cover things to an extent, but not that well. Maybe Discourse would work here, though we would need to make sure it
> doesnt get overrun with support/general questions otherwise it seems it would be pretty ineffective. We need an easy way for teams to manage
> release planning, TODO lists, track release notes etc
Do the other teams use Discourse? If so, why don't we? More accessible 
to everyone than slack imho.
>
> I have wondered if simplifying the team structures would help, I know Ali went to a lot of work to setup all the different sub-teams, and it
> seemed like a great idea at the time, it just hasn’t worked out that great. In my opinion, sandboxing users in micro managed teams, limits their
> contributions to that niche. We already merged a couple of teams recently, however I think we should strip it right back to about 3 teams,
> Technical (dev/qa), community and marketing or something like that.
Would seem like a logical step. Less clutter = more better.