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...@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...@gmx.net > http://blogs.gnome.org/aklapper/ > >
_______________________________________________ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.