Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 08:33:43PM -0700, Sriram Ramkrishna wrote: What about you want to use a new technology but you don't want any new features but rather using this new external dependency will simpifiy things and making maintainance easier? I suppose that itself is the feature? Easier maintenance? That's #3 actually; propose a new external dependency (same as you do when you want to increase a new one). I know the process is still imperfect (e.g. I think we didn't do a feature request announcement yet, we should clearly announce which ones are 'accepted' + should've monitored the progress on accepted features). Result is that it that the 'rules' are unclear. I think in the end focussing on features instead of external dependencies is better. But I think the thought is still underway. Risk for the feature focus is that the external dependencies rules are forgotten. E.g. I noticed that gnome-boxes increased its libosinfo version requirement in 3.4.1. That's not so nice when distribution is in a version freeze. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Hi Olav, Thanks a lot for clearing it up. This makes a lot of sense. As I see it there is two ways to approach this: 1) Implement first then propose as an external dependency:The risk is that implementation is done and GNOME decides the dependency is unacceptable, thus rendering a couple of months work useless. And if the application persists then it is almost like its shoving a dependency down the communities throat. 2) It is blessed to use the technology. This way we valuable time is saved and there is consensus. I prefer option 2. What do you think? Cheers Seif On Sun, Apr 22, 2012 at 12:14 PM, Olav Vitters o...@vitters.nl wrote: On Sat, Apr 21, 2012 at 08:33:43PM -0700, Sriram Ramkrishna wrote: What about you want to use a new technology but you don't want any new features but rather using this new external dependency will simpifiy things and making maintainance easier? I suppose that itself is the feature? Easier maintenance? That's #3 actually; propose a new external dependency (same as you do when you want to increase a new one). I know the process is still imperfect (e.g. I think we didn't do a feature request announcement yet, we should clearly announce which ones are 'accepted' + should've monitored the progress on accepted features). Result is that it that the 'rules' are unclear. I think in the end focussing on features instead of external dependencies is better. But I think the thought is still underway. Risk for the feature focus is that the external dependencies rules are forgotten. E.g. I noticed that gnome-boxes increased its libosinfo version requirement in 3.4.1. That's not so nice when distribution is in a version freeze. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sat, Apr 21, 2012 at 9:28 PM, Luis Medinas lmedi...@gnome.org wrote: do you really want to start talking about what the community think about this ? Because if you want to start talking i recommend to see how many threads we have, specially on gnome-shell ml, about design decisions that makes the community powerless against the almighty Design Team. ... and from before the design team even existed, there are even more threads about design decisions that make the community powerless against the almighty GNOME Developers - the (rightful) answer to that is usually don't just complain, get involved. The same still holds true with the design team - really, those folks would *love* seeing more people getting involved. Regards, Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Then the design team ought to be more open about what exactly 'their' vision for gnome is, as well as open to other ideas/concepts. Insisting on doing things their way, while being extremely vague as to what exactly their way *is* is not helpful to the rest of the community who is trying to get stuff done. IMHO the entire community is rather insulated from itself and rather hard to break into w/o serious help from someone already on the 'inside' as it were. If you haven't been around for years, no-one seems to particularly care what you have to say. Even finding these sorts of discussions isn't exactly easy, let alone making your voice heard. Emily On Sun, Apr 22, 2012 at 10:11 AM, Florian Müllner fmuell...@gnome.orgwrote: On Sat, Apr 21, 2012 at 9:28 PM, Luis Medinas lmedi...@gnome.org wrote: do you really want to start talking about what the community think about this ? Because if you want to start talking i recommend to see how many threads we have, specially on gnome-shell ml, about design decisions that makes the community powerless against the almighty Design Team. ... and from before the design team even existed, there are even more threads about design decisions that make the community powerless against the almighty GNOME Developers - the (rightful) answer to that is usually don't just complain, get involved. The same still holds true with the design team - really, those folks would *love* seeing more people getting involved. Regards, Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Whatever you can do, or dream you can, begin it. Boldness has genius, power and magic in it. - Goethe Be who you are and say what you feel because those who mind don't matter and those who matter don't mind. - Dr.Seuss Not everything that can be counted counts, and not everything that counts can be counted. - Albert Einstein ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On 22 April 2012 06:14, Olav Vitters o...@vitters.nl wrote: Risk for the feature focus is that the external dependencies rules are forgotten. E.g. I noticed that gnome-boxes increased its libosinfo version requirement in 3.4.1. That's not so nice when distribution is in a version freeze. Off-topic, Ubuntu 12.04 won't have Boxes in the repositories, at least partly because the libvirt dependency was increased 2 weeks after The Freeze. But this was the first stable release of Boxes, I'm sure things will be better for 3.6. Jeremy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
I agree with Florian here. It took me a bit of time to interact with the design team but it is possible. It is a very young team and extremely busy and overloaded. They are welcoming for anyone to work with them on design and once you get their attention they will help you integrate more. The best way to be heard is to get involved. But I also understand Luis. I have been working with Allan Day and others for a while now and they are a very productive. The missing point here is that maybe and only maybe because most of the designers are hired by RH (which i consider a blessing if you get paid to work for GNOME), they forget the social capital which is the community, that will implement the work they design. Without interaction with the community no work will be done. And by saying this has to be done because it was decided without any written form or communication it makes things harder. Yes I know there is a wiki but sometimes a developer wants to discuss design decisions but due to the lack of communication efforts from both sides, it seems that the decisions are taken by the design team. My point is that designers should communicate and respect the opinions of the developers. Developers don't just wait to the last moment. Get involved and discuss. I know every side has its own priorities, but we are a community and discussions and compromises need to be made. We want to deliver a product. Some of us get paid to do this, but not all of us. Most of us do it as fun and in our free time. We are a community, this means there is a social aspect involved. And if we can not nurture this social aspect, issues like these show up. Maybe the decision process is flawed. Sometimes technical aspects can not be decided by the design team and thus I would recommend having 2 types of proposals. a feature proposal (UX) and a module proposal (technical stuff). Regards Seif On Sun, Apr 22, 2012 at 4:11 PM, Florian Müllner fmuell...@gnome.org wrote: On Sat, Apr 21, 2012 at 9:28 PM, Luis Medinas lmedi...@gnome.org wrote: do you really want to start talking about what the community think about this ? Because if you want to start talking i recommend to see how many threads we have, specially on gnome-shell ml, about design decisions that makes the community powerless against the almighty Design Team. ... and from before the design team even existed, there are even more threads about design decisions that make the community powerless against the almighty GNOME Developers - the (rightful) answer to that is usually don't just complain, get involved. The same still holds true with the design team - really, those folks would *love* seeing more people getting involved. Regards, Florian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
While this thread reflects a bit about some community observations on how things are handled in GNOME, and i support such a discussion, I find it a bit off-topic. Can we start a new thread discussing these issues or so. Let us stay on topic. Can an applications use Zeitgeist for technical/optimization (NOT FEATURES OR UX) causes? And how does it proceed? 1) Implement first and require dependency later. 2) Request blessed dependency and then implement, if the blessing is given. I would like to know an answer from the release-team if possible, since this is not really design related. Cheers Seif On Sun, Apr 22, 2012 at 4:36 PM, Jeremy Bicha jbi...@ubuntu.com wrote: On 22 April 2012 06:14, Olav Vitters o...@vitters.nl wrote: Risk for the feature focus is that the external dependencies rules are forgotten. E.g. I noticed that gnome-boxes increased its libosinfo version requirement in 3.4.1. That's not so nice when distribution is in a version freeze. Off-topic, Ubuntu 12.04 won't have Boxes in the repositories, at least partly because the libvirt dependency was increased 2 weeks after The Freeze. But this was the first stable release of Boxes, I'm sure things will be better for 3.6. Jeremy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sun, Apr 22, 2012 at 4:27 PM, Emily Gonyer emilyyr...@gmail.com wrote: Then the design team ought to be more open about what exactly 'their' vision for gnome is, as well as open to other ideas/concepts. Insisting on doing things their way, while being extremely vague as to what exactly their way *is* is not helpful to the rest of the community who is trying to get stuff done. First: the design team is very much trying to get stuff done, just like the rest of the community. In fact, the design team is incredibly small (ergo: overworked). We have an extremely ambitious goal of creating an operating system, with just a handful of people doing design work towards that goal - compare that to the resources the likes of Apple or Microsoft put into their products to get an idea of the workload our folks have. I certainly have seen maintainers asking for design help on #gnome-design being turned down because no designer had any time to spend on yet-another-module. Which brings us to the matter of openness: the results of everything the design team does ends up on the GNOME wiki under live.gnome.org/Design. Of course it would be really fancy if the wiki also contained the reasoning behind decisions, but let's face it - none of us does anything like that (I doubt you are adding comments like Using a full-blown GObject rather than a boxed type here because ... or This variable is a double and not an integer because ... to your code - I certainly don't. Still, wouldn't that be helpful for newcomers?). So what about the overall vision then? I don't disagree with you at all in that it is often pretty vague - not because the design team is being secretive about it, but because it is work-in-progress that we(*) are developing together as a community. Also, it is worth pointing out that the power of the design team is very much limited to convincing developers and maintainers of their work - if a design is not implemented, it pixel-rots on the wiki, if a maintainer does not like a patch, it doesn't get committed. IMHO the entire community is rather insulated from itself and rather hard to break into w/o serious help from someone already on the 'inside' as it were. If you haven't been around for years, no-one seems to particularly care what you have to say. Even finding these sorts of discussions isn't exactly easy, let alone making your voice heard. From my own personal experience, I'd say that from the outside it looks a lot harder than it actually is, but that doesn't mean that there is no problem. Still, it is something that applies for the community at large, not just the design team - if someone presents a radical new vision for GTK+, it is very much relevant whether someone is Benjamin Otte or Emmanuele Bassi, or someone no one has ever heard of ... Regards, Florian (*) to clarify, that we includes developers - I don't identify myself as a member of the design team, but as GNOME hacker who gets along fine with them :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Openness (Was: Re: Module Proposal: Zeitgeist)
On Sun, 2012-04-22 at 18:21 +0200, Florian Max wrote: Which brings us to the matter of openness: the results of everything the design team does ends up on the GNOME wiki under live.gnome.org/Design. I think people are more concerned about being able to have input on the process, not on seeing the results published on the wiki. I'm on #gnome-design all day. I often skim the backlog. I don't really see the discussion that leads to the results. Sometimes I see mention of meetings. I don't know where those meetings happen. Of course it would be really fancy if the wiki also contained the reasoning behind decisions, but let's face it - none of us does anything like that (I doubt you are adding comments like Using a full-blown GObject rather than a boxed type here because ... or This variable is a double and not an integer because ... to your code - I certainly don't. Still, wouldn't that be helpful for newcomers?). That sounds like exactly the sort of thing I write in my git commit messages. I hope you do too. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
In the end your history is scattered all over the place :P The logs are there and there is not common way to manage them. Having a central log like Zeitgeist will allow you to develop policies and blacklist for logging. Having history at a central location and having a central tool to disable logging completely or partially should be considered as an improvement of the user security. The problem I see here is that it only improves the situation if it is truly universal - if a central privacy control offers an option to remove my recent activity from the last 2 hours, it'd better clear my firefox/chromium cookies as well(*). Otherwise users will either have to know about implementation details, or will end up with a false sense of control. Also - if I want to hide my recent activity on http://www.furnitureporn.com/, should that really affect funnycat1.png in recent files or my chat history with @fiancé? I am not saying that a central tool is bad per se, just that a feature like that should be designed *before* pushing a technology that implies a certain design. Regards, Florian (*) Maybe Canonical's downstream panel does that, I don't know - they are in a much stronger position here than we are upstream ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sun, Apr 22, 2012 at 7:09 PM, Florian Max florian.muell...@gmail.com wrote: In the end your history is scattered all over the place :P The logs are there and there is not common way to manage them. Having a central log like Zeitgeist will allow you to develop policies and blacklist for logging. Having history at a central location and having a central tool to disable logging completely or partially should be considered as an improvement of the user security. The problem I see here is that it only improves the situation if it is truly universal - if a central privacy control offers an option to remove my recent activity from the last 2 hours, it'd better clear my firefox/chromium cookies as well(*). Otherwise users will either have to know about implementation details, or will end up with a false sense of control. First of all thank you for bringing us on topic again. I agree with you. There is more to privacy than history. Cookies etc are involve. I am just saying history is a part of it. We can start from there. We all agree that design and implementation is iterative. Chrome is not a core app. GNOME should focus on the core apps (as stated by the designers) so a privacy manager should take only GNOME apps into consideration per default. Also - if I want to hide my recent activity on http://www.furnitureporn.com/, should that really affect funnycat1.png in recent files or my chat history with @fiancé? I am not saying that a central tool is bad per se, just that a feature like that should be designed *before* pushing a technology that implies a certain design. I totally 100% agree with you that from a UX perspective this needs much more design. And I already said I am not interested anymore in adding a new feature from a UX perspective. But just as a side note. The technology is there. Which means one you want to add a privacy thing it is there, and please believe me that managing your history via Zeitgeist is much more powerful than you give it credit. You can single out stuff and do whatever. It is missing a good UI. So I would still like to have my question answered. How is the policy on using Zeitgeist for non-feature and non-UX related optimization and maintenance distribution? Regards, Florian (*) Maybe Canonical's downstream panel does that, I don't know - they are in a much stronger position here than we are upstream Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Openness (Was: Re: Module Proposal: Zeitgeist)
Sv, 2012-04-22 12:36 -0400, Shaun McCance rakstīja: On Sun, 2012-04-22 at 18:21 +0200, Florian Max wrote: Which brings us to the matter of openness: the results of everything the design team does ends up on the GNOME wiki under live.gnome.org/Design. I think people are more concerned about being able to have input on the process, not on seeing the results published on the wiki. I'm on #gnome-design all day. I often skim the backlog. I don't really see the discussion that leads to the results. Sometimes I see mention of meetings. I don't know where those meetings happen. Does design team use anything like meetbot? http://meetbot.debian.net/Manual.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sun, Apr 22, 2012 at 9:21 AM, Florian Max florian.muell...@gmail.comwrote: On Sun, Apr 22, 2012 at 4:27 PM, Emily Gonyer emilyyr...@gmail.comwrote: Then the design team ought to be more open about what exactly 'their' vision for gnome is, as well as open to other ideas/concepts. Insisting on doing things their way, while being extremely vague as to what exactly their way *is* is not helpful to the rest of the community who is trying to get stuff done. First: the design team is very much trying to get stuff done, just like the rest of the community. In fact, the design team is incredibly small (ergo: overworked). We have an extremely ambitious goal of creating an operating system, with just a handful of people doing design work towards that goal - compare that to the resources the likes of Apple or Microsoft put into their products to get an idea of the workload our folks have. I certainly have seen maintainers asking for design help on #gnome-design being turned down because no designer had any time to spend on yet-another-module. I think we have a bit of a problem. Our core team has gotten smaller and thus overworked. Because of that they don't have that kind of time to do community management. I would even say that some of you are kinda grumpy. :-) We really need to grow the number of good quality coders. Things like creating a lower bar of entry to code on GNOME is one aspect of an overall problem of getting new blood. It's why we have a perception of companies running the joint rather than a community. GNOME as a project needs to concentrate on bringing in new volunteers so that we can expand the core team. Which brings us to the matter of openness: the results of everything the design team does ends up on the GNOME wiki under live.gnome.org/Design. Of course it would be really fancy if the wiki also contained the reasoning behind decisions, but let's face it - Shaun opened up a new thread on this, I will pen my thoughts there. Great thoughts, Florian. Thanks. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Openness (Was: Re: Module Proposal: Zeitgeist)
On Sun, Apr 22, 2012 at 6:36 PM, Shaun McCance sha...@gnome.org wrote: On Sun, 2012-04-22 at 18:21 +0200, Florian Max wrote: Which brings us to the matter of openness: the results of everything the design team does ends up on the GNOME wiki under live.gnome.org/Design. I think people are more concerned about being able to have input on the process, not on seeing the results published on the wiki. I'm on #gnome-design all day. I often skim the backlog. I don't really see the discussion that leads to the results. Sometimes I see mention of meetings. I don't know where those meetings happen. Exactly. Non-designers want to be part of the process. Reasons behind decisions need to be written somewhere, but that is not enough. If a new a developer comes and asks for reasons behind a decisions, I doubt that the designers, who are already as busy as it gets, can take time to explain each one who comes over what problem is being solved via the design and how. So having design decisions and their reasoning documented would help. But also as designers it is their responsibility to communicate with those who still doubt these decisions, starting with those willing to implement or help out directly. Because if they can explain to those nearest to them, those can then jump in to help others. So I think my point here is. Documenting is important but communication is key. I get it when designers think that they can spend your whole time trying to convince people of a vision, but at some point something needs to be done. I agree to a certain extent. But who will do it? The paid developers. Well this would make us lose the community on the long run. We need to work on communication between designers and developers. Build trust. Designers have to take time and push themselves to be patient with developers and explain to them seems to them to be trivial facts. Once developers understand how hard a designers job is they will respect it and trust in the decisions and vision, even if they don't agree in the beginning. But also designers need to work on growing they base. The entry level is not that easy I guess. We need to work on basics. If someone comes with designs that are not suitable for us, we can't just pus him away. The fact that he/she came over to discuss designs with us shows initiative to contribute. So some slight wording like You know that is really good, I am not sure how it can fit in our designs but would you try taking this view out and show me etc... We are not selling GNOME to consumers only. We are selling the community too. I like the subject of this thread, because openness does not only reflect on the decisions making process but also on the openness to accept new contributors. Cheers Seif Of course it would be really fancy if the wiki also contained the reasoning behind decisions, but let's face it - none of us does anything like that (I doubt you are adding comments like Using a full-blown GObject rather than a boxed type here because ... or This variable is a double and not an integer because ... to your code - I certainly don't. Still, wouldn't that be helpful for newcomers?). That sounds like exactly the sort of thing I write in my git commit messages. I hope you do too. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Openness (Was: Re: Module Proposal: Zeitgeist)
On Sun, Apr 22, 2012 at 1:06 PM, Seif Lotfy s...@lotfy.com wrote: On Sun, Apr 22, 2012 at 6:36 PM, Shaun McCance sha...@gnome.org wrote: On Sun, 2012-04-22 at 18:21 +0200, Florian Max wrote: Which brings us to the matter of openness: the results of everything the design team does ends up on the GNOME wiki under live.gnome.org/Design. I think people are more concerned about being able to have input on the process, not on seeing the results published on the wiki. I'm on #gnome-design all day. I often skim the backlog. I don't really see the discussion that leads to the results. Sometimes I see mention of meetings. I don't know where those meetings happen. Exactly. Non-designers want to be part of the process. Reasons behind decisions need to be written somewhere, but that is not enough. If a new a developer comes and asks for reasons behind a decisions, I doubt that the designers, who are already as busy as it gets, can take time to explain each one who comes over what problem is being solved via the design and how. So having design decisions and their reasoning documented would help. But also as designers it is their responsibility to communicate with those who still doubt these decisions, starting with those willing to implement or help out directly. Because if they can explain to those nearest to them, those can then jump in to help others. No, you get volunteer community managers to communicate those design decisions. A community manager should be able to get a general feel of what design decisions are having issues with the community. At some point maybe sucha person can opt for a conversation with specific individuals but otherwise you know there are a lot of unreasonable people out here and the internet makes them more unreasonable than they would be usually. Luckily for us, we do have a number of people who couldu do that kind of community management, Olav for one has already been doing some of it. I do it more externally. Big projects like Mozilla have a community managers. It's definitely something this project should do more of. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Openness (Was: Re: Module Proposal: Zeitgeist)
On Sun, Apr 22, 2012 at 10:18 PM, Sriram Ramkrishna s...@ramkrishna.me wrote: On Sun, Apr 22, 2012 at 1:06 PM, Seif Lotfy s...@lotfy.com wrote: On Sun, Apr 22, 2012 at 6:36 PM, Shaun McCance sha...@gnome.org wrote: On Sun, 2012-04-22 at 18:21 +0200, Florian Max wrote: Which brings us to the matter of openness: the results of everything the design team does ends up on the GNOME wiki under live.gnome.org/Design. I think people are more concerned about being able to have input on the process, not on seeing the results published on the wiki. I'm on #gnome-design all day. I often skim the backlog. I don't really see the discussion that leads to the results. Sometimes I see mention of meetings. I don't know where those meetings happen. Exactly. Non-designers want to be part of the process. Reasons behind decisions need to be written somewhere, but that is not enough. If a new a developer comes and asks for reasons behind a decisions, I doubt that the designers, who are already as busy as it gets, can take time to explain each one who comes over what problem is being solved via the design and how. So having design decisions and their reasoning documented would help. But also as designers it is their responsibility to communicate with those who still doubt these decisions, starting with those willing to implement or help out directly. Because if they can explain to those nearest to them, those can then jump in to help others. No, you get volunteer community managers to communicate those design decisions. A community manager should be able to get a general feel of what design decisions are having issues with the community. At some point maybe sucha person can opt for a conversation with specific individuals but otherwise you know there are a lot of unreasonable people out here and the internet makes them more unreasonable than they would be usually. Good point. With community managers, designers can focus more. Still I think a minimal interaction with the community from the designers side is required. I think going with some kind of liaison is a good direction. Luckily for us, we do have a number of people who couldu do that kind of community management, Olav for one has already been doing some of it. I do it more externally. Are you talking about Olav Bacon :P (bad joke, trying to lighten the mood a bit) Big projects like Mozilla have a community managers. It's definitely something this project should do more of. Dave Eaves who is a Mozilla Community manager has a very nice talk I encourage everybody to watch it. http://blip.tv/djangocon/keynote-david-eaves-5571777 sri Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
