Re: 3.18 topics: application revival



Hello Andre,

> We already mirror on GitHub (but I have not checked how clearly we say
> that it is just a mirror and if we point to

Github mirror is good enough to watch the changes on a project, but since you can't report
and follow bugs, isn't very helpful 


https://wiki.gnome.org/Git/Developers ). If you refer to entirely moving
> to GitHub: I dislike the idea of relying on closed source software.

"Dislike" isn't quite a reason ;)
Plus you don't relying on Github, you're just using it. You can move away at any time, if a reason comes
up. Which is unlikely judging from Github history.

Could you elaborate? What kind of "communication"?

Clearly GNOME gets most of the feedback from BGO. Even if you call an "annoyance" on Google+, 
a common response will be, please file a bug. Bugzilla isn't designed to play that role. It's only for developers.
Further more, what I'm telling is that projects on Github, with smaller user base than GNOME, get more
feedback from more users.

> Most distros release every 6-9 months. When it comes to distribution of
> our product, GNOME is not directly shipped to end-users. The described
> problem would mostly remain except for those users on rolling releases.

Most? Pretty sure you're talking mostly about Fedora here. Ubuntu is out of the question, 
openSUSE is trying to move to RR, Debian isn't 6 months plus they have Sid which is popular
enough. The rest of distros that aren't derivatives of the above, are kinda insignificant, plus
their up to them to adjust their software update policies. 

But AFAIK, Fedora for example updates Firefox. They can do the same with 
Gnome Music for example. The idea here, is that you can't have a cool new feature or a major bug fix 
lying on Git, that you can't ship it coz of release policies. 

> Have more acceptance

I mean that you need to identify the reasons why people prefer to contribute on new projects, or in projects
like elementary. For example, comparing the sizes of elementary and GNOME, elementary attracts more
contributors for their apps than GNOME. And I'm talking about no-paid contributors. 
As I said before, if someone won't treat a project as "her own property", she won't care enough to improve it.
And that is happening in things under GGO. 

In general I feel that GNOME is "acting" like it's a big C library for nerds, rather a modern community operating
system, for everyone. In my opinion, Wikis, Docs, Feedback mechanisms, and communication need a bit more
attention. 

Also I think the initial question is pretty much irrelevant. GNOME Project / Desktop goal shouldn't even be
writing applications. Provide the tools, and let people write them.

- alex


On Sat, Apr 18, 2015 at 1:48 AM, Andre Klapper <ak-47 gmx net> wrote:
On Thu, 2015-04-16 at 01:12 +0300, alex diavatis wrote:
> 1) Move to Github. More advertisement, easy to watch the changes,
> obvious advantages.

We already mirror on GitHub (but I have not checked how clearly we say
that it is just a mirror and if we point to
https://wiki.gnome.org/Git/Developers ). If you refer to entirely moving
to GitHub: I dislike the idea of relying on closed source software.

> A notice here, BGO has poor communication outside of GNOME developers,
> in comparison with smaller projects in Github.

Could you elaborate? What kind of "communication"?
>
> 2) Change release cycle schedule on applications. I don't believe that
> people are very excited to contribute on something
> and wait for 6 months to see it "live" coz of UI freeze policy. It's
> bad for users and for development in general too.
>
Most distros release every 6-9 months. When it comes to distribution of
our product, GNOME is not directly shipped to end-users. The described
problem would mostly remain except for those users on rolling releases.
>
> 3) Have more acceptance. I know you may don't want some "features",
> but it is better than having an
> under-development module. Plus these contributors are likely to work
> on other things as well.

Do you refer to "earlier" make contributors co-maintainers and work on
having "lower expectations" when it comes to gaining trust? We have e.g.
https://git.gnome.org/browse/evolution/stats/?period=y&ofs=10 showing us
names of contributors (code, translations, docs) per module, but we have
nothing in place to tell us "This user does not have Git commit rights".
And nothing either to identify the actual Git activity of a maintainer
who might be listed in the DOAP file but has not been active for ages.

Cheers,
andre

--
Andre Klapper  |  ak-47 gmx net
http://blogs.gnome.org/aklapper/




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]