Communications 2.0

[Narcis Garcia]

About website, I suggest 2 measures:

1. Better appearance theme

2. More menu options. My proposal for menus structure:

1. About/Discover
{What is Ubuntu-Gnome, features, license, requirements, screenshots}

2. Install/Download
{Downloads, install guides, more resources}

4. Get help/Participate
{Documentation, Bugs tracker, Forums, Mailing list}


El 02/05/16 a les 16:09, Jasper Backer ha escrit:
> 
> 
> 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.
> 
>