Re: Rules for design in Gnome
On Wed, Apr 25, 2012 at 20:51, Jason D. Clinton m...@jasonclinton.com wrote: My question to you would be, why didn't agreement ever get reached? Why, four years later, are we still arguing about desktop activity? I see a failure of cooperation; not of the design team's but rather of the whole project's. Wonder if besides improving in-project cooperation, we shouldn't make it easier as well for people with diverging ideas to prove that they are right. I see how it can be a problem for the GNOME brand if individual distros ship too big modifications to the upstream, official GNOME releases, but giving the chance to people to push forward their ideas if they believe in them has also its value. Innovation happens as convergence after divergence, if we stress the first too much, our capacity to innovate slows down. Regards, Tomeu ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
Tomeu: On 04/26/12 02:06 AM, Tomeu Vizoso wrote: On Tue, Apr 24, 2012 at 15:10, Alberto Ruizar...@gnome.org wrote: I'm afraid that interfering in the maintainer's responsibilities is a very big can of worms, more likely to do harm than good. There's something powerful in how a maintainer feels responsible about his module and the community that surrounds it. Some of my thoughts about the GNOME maintainer community, aside from the fact that they do a great job. 1) There really are not any good forums for communicating with core GNOME maintainers as a group. Looking at MaintainersCorner I see that GNOME only requires maintainers to subscribe to devel-announce-list. I suppose much communication happens on desktop-devel-list and foundation-list, but it seems hard to figure out how to have a dialog with the maintainers as a group or how to make decisions. A lot of problems might solve themselves if we made it easier for maintainers to focus on decision making when needed. 2) Many distros are currently supporting GNOME 2 based distros. While I think it is good that our development community is focused on GNOME 3, it is also important to encourage distros to cooperate as they maintain GNOME 2 and keep it working well so that the brand is strong and positive. I remember Vincent suggesting that core GNOME 2 modules might need additional maintainers in order to provide ongoing support to do cooperative efforts like this. To make something like this work well requires coordination and decision making amongst maintainers. Providing more support for more branches might require more infrastructure. It seems it should be possible to strike a better balance between focusing energy on new development while providing more impressive support for those who continue to depend on GNOME 2. I'd say there is probably enough topics to warrant having a Maintainers BOF or something at GUADEC where topics like this might be discussed. I think it would be great if we could find new ways to augment our maintainer community, or to make our decision-making processes easier and more transparent. And probably a good forum to discuss what sorts of Usability rules resonate most with maintainers. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
Why did I write that mail? First of all, I'm very sorry for doing precisely what I was trying to prevent - alienating people. I wrote that mail in anger, always a bad idea. I owe everyone, and especially the design team, an explanation. In Gnome we are going through a period where there is a important group of developers that feel disenfranchised. These are not people on the fringe of Gnome, but hackers close to the core. We have been in a similar situation before. Not all of the people to whom I referred indirectly in my other mail were around at that time, so allow me to tell that story. The beginning of the Gnome 2.x series was a very painful time. The major companies involved in Gnome were in vicious competition, with everyone blaming the others for trying to gain control of Gnome. The first rounds of usability testing had happened late in the Gnome 1.x series, and everyone was starting to understand what easy to use software really meant. We had to kill or rewrite a lot of code from Gnome 1.x to achieve a simpler and more coherent system. Things just didn't work very well during the first Gnome 2.x releases. A big meme at that time was that software needed to be as simple as possible in its presentation to the user - as few options and commands as possible, and everything simplified so that beginners would not get confused. People wrote very enlightening essays about the virtues of simple user interfaces. We had a rather new Human Interface Guidelines document, which could be used as a reference for keeping things consistent (12 pixel spacing between widgets; such and such capitalization for menu items). We made Gnome 2.x work well; it was simple to use, the UI looked clean, and developers successfully internalized many of the ideas that we had struggled to push through earlier. It was a great victory to see that throughout Gnome, instead of random hacking we had people basing every decision on whether the resulting software would be consistent and easy to use. And then, people wanted to take Gnome further: add more functionality to existing software; integrate new things into the core; make things more complex but with good reason. However, the keep things simple and stable meme got taken too far. Proposals to add functionality got shot down. Modules couldn't be integrated. In trying to keep things simple and stable, and in trying to polish existing things rather than creating new ones, a loose and small group of people were inadvertently alienating those who wanted to do new kinds of development in Gnome. There was a lot of discomfort because Gnome seemed stagnant. Someone came up with the term UI Nazis and it stuck, Godwin's Law and all. Things got near to the breaking point when Nat Friedman gave a keynote address during GUADEC 2004, titled Swinging the Pendulum. You can see it at http://nat.org/NatFriedman-GUADEC-5-Pendulum.sxi One of the main points of Nat's talk was that we were at a point where Gnome was ignoring innovation for fear of losing simplicity. His presentation had a section called barriers to hacking, where he had items like lack of tools, but also items like lack of community, embarrassment (because your work is not seen as good enough), humiliation (because you get told that you are not up to Gnome's standards), and ridicule (you think *that* is a good UI? It doesn't even follow the HIG!). There is a big slide in that talk that says, We need the cultural freedom to innovate. From what I've seen happen since the start of Gnome 3, we are at a similar period right now, where groups of Gnome developers are in discomfort because the dynamics of the project are working against them. You could say that in Gnome 2 our meme was, keep things simple for the user, and in Gnome 3 our meme is, design first, then develop. BOTH ARE GOOD THINGS TO DO! The problem is when you do too much of each. We tried to keep things *too* simple, so we couldn't innovate. Now that design is at the forefront, we have these happening: * People feel like the design team has to give them permission to write things. * People feel like they can't come up with (visual/interaction) designs on their own because it is the design team that does that. * People write well-reasoned emails explaining things, and apologize at the end with ... but I'm not a designer.. * The feature proposal process is vague. We had a module proposal process that is not ideal for everything (especially horizontal changes that involve many modules), but at least there was a clear way to get a new module integrated. And the thing is, THE DESIGN TEAM DID NOT INTEND FOR ANY OF THIS TO HAPPEN! During Gnome 2, we had many of the top-tier hackers simply leave the project, one by one, because they got tired about all the bickering. They now contribute elsewhere where they don't have to bicker as much. I don't want to have situation in Gnome 3 where we lose good hackers due to the current situation.
Re: Rules for design in Gnome
Will probably regret writing this email, but here it goes, anyway. On Wed, Apr 25, 2012 at 11:09 AM, Federico Mena Quintero feder...@gnome.org wrote: One of the main points of Nat's talk was that we were at a point where Gnome was ignoring innovation for fear of losing simplicity. His presentation had a section called barriers to hacking, where he had items like lack of tools, but also items like lack of community, embarrassment (because your work is not seen as good enough), humiliation (because you get told that you are not up to Gnome's standards), and ridicule (you think *that* is a good UI? It doesn't even follow the HIG!). There is a big slide in that talk that says, We need the cultural freedom to innovate. From what I've seen happen since the start of Gnome 3, we are at a similar period right now, where groups of Gnome developers are in discomfort because the dynamics of the project are working against them. On the topic of history, I think that we can say with hindsight that the later days of GNOME 2's lifespan (and the disjointed OS/tech stack underneath it) cannot be held on a pedestal. We were handed a golden market opportunity on a silver platter in the form of netbooks from ISV's who actively sought *us* out, went about shipping, and offered support for GNOME pre-installed on them--well in advance of the march of the Tablet Empire. Just think about all of the thousands of people in the supply chain from multiple vendors that were required to make that happen and then think about trying to pull that off again. I hope that you feel that our failure there was a tragedy. The market flat-out rejected what we had to offer. Sure, any module proposal could get accepted in to GNOME at that time but to what end? Technology that a user or a platform developer cannot use because it isn't usable isn't technology at all: it's techurbation. But there is, as there always has been, a way forward: the people who have a passion for a technology that they have brought in to this world obviously envision a way for it to become accessible to users. I know that you and Seif have that vision: I saw your presentation on Journal at the 2008 Hackfest and thought to myself, Fuck, yes! We *can* get there and indeed I have watched multiple threads over the past four years on this and related desktop activity logs topics propose ways forward. What I have seen from the outside, though, is that the discussions always fizzled with disagreement. My question to you would be, why didn't agreement ever get reached? Why, four years later, are we still arguing about desktop activity? I see a failure of cooperation; not of the design team's but rather of the whole project's. (My views do not in any way represent those of Google.) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
Hello Federico, Em Mon, 2012-04-23 às 20:58 -0500, Federico Mena Quintero escreveu: snip From http://live.gnome.org/CodeOfConduct Assume people mean well From your mail: The design team IS NOT welcome to: * Second-guess maintainers or well-intentioned contributors. * Block development based on existing designs. * Block development based on incomplete or planned designs. * Veto development except in modules with branches that the design team maintains. * Be dismissive of other people's own approaches to design. * Dismiss or handwave requests for clarification about decisions taken. * Assume that no one but them does design that is good for Gnome. I think an apology is in order. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
On Tue, Apr 24, 2012 at 3:58 AM, Federico Mena Quintero feder...@gnome.org wrote: The design team IS NOT welcome to: * Second-guess maintainers or well-intentioned contributors. Surely the Design Team is also composed of well intentioned contributors that only want the best for Gnome and do not deserve this kind of attack? Basically: * We don't have a hierarchy in Gnome. You don't get to say what other people may develop. The release team is our final sanity check so that we don't ship non-working garbage. If you are a module maintainer you get to set the rules within that module, and nowhere else, and other people can fork you as they please. This does not seem compatible with an email that says Rules for design in Gnome, followed by a list of things people CAN and CANNOT do. Unless the whole thing is one long joke, and not a very funny one. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
hi Federico; I think this email is not at all warranted - and it generates more fuel for flames. On 24 April 2012 02:58, Federico Mena Quintero feder...@gnome.org wrote: The design team IS welcome to: The design team IS NOT welcome to: these elements contradict what you write below * Second-guess maintainers or well-intentioned contributors. * Block development based on existing designs. * Block development based on incomplete or planned designs. * Veto development except in modules with branches that the design team maintains. * Be dismissive of other people's own approaches to design. * Dismiss or handwave requests for clarification about decisions taken. here: * Every decision is up for review. The state of the world changes, not everyone shares your assumptions, and matters which seem settled may need revision. so, if every decision is up for review, why shouldn't the people doing design second-guess or block? finally, and particularly, this is wrong: * Assume that no one but them does design that is good for Gnome. if you're designing for Gnome, then *by definition* you are on the Gnome design team. if your designs are in conflict with what other people doing design are trying to achieve, then you should talk to them, and revise them and/or achieve a rough consensus on what is the direction to take. by the way, since we're dropping rules by fiat, and given that at least I'm empowered by the fact of having been elected on the Foundation's board, I think people on this list are welcome to assume that people mean well, and are NOT welcome to assume conspiracies or assume that people do stuff just because. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
OK first let us all please calm down (This does not apply to Emmanuele, since he seems always calm :P) We all have the best intentions at heart. I think Federico knows exactly that the design team has best intentions. And I hope the design team knows that Federico has the same intentions. This thread sums up and shows the communication flaws between the design team and some of us in the community. There must be a reason why this E-mail was sent and it is not to flame or anger people. We are discussing a problem here. We all agree that: - *No one is in charge. GNOME designers know they don't decide on behalf of GNOME.* - *We are trying to build a product here. * Yet how can we build a product if *some* developers don't feel attached to what they are contributing to. Should those leave the community just because they don't share the vision of the design team. If a designer designs a feature for an application, but the maintainer of the app does not like it, who will implement it? And the other way round we can not develop applications without designing them else no one will use them and we will lose a developer base. There is a perception that GNOME design team are the ones decided the direction. This perception did not come out of thin air and is not a conspiracy. It is a communication problem. From my observation I think the design team cares more about building the product and sometimes forgets about the community and the social capital of GNOME. This might be based on the fact that *most* of the designers are hired by companies. So if a maintainer doesn't want to implement their designs they can rely on the financial capital to make it happen. This leads to some *developers feeling helpless about how to influence the direction of GNOME* * * Also some designs of applications are not done, and mostly are a revamp of currently existing applications. Suggesting adding a feature to one of the applications is the considered invalid because they don't fit the future plans of the design (that might not be done). Can a developer add such a feature without the design team getting upset? As someone who held a grudge for around 2 years against the design team, I managed to somehow communicate with them in the last 6 months. And they are awesome. Once the communication bridge opened I now understand them and enjoy working with them == I trust their ideas. But I still see the how hard it is to get to them. It was not easy. So communication efforts have to be done from both sides. If designers expect developers to implement their ideas then they should also tolerate and work around the fact that developers want to implement their own ideas. Cheers Seif On Tue, Apr 24, 2012 at 12:08 PM, Emmanuele Bassi eba...@gmail.com wrote: hi Federico; I think this email is not at all warranted - and it generates more fuel for flames. On 24 April 2012 02:58, Federico Mena Quintero feder...@gnome.org wrote: The design team IS welcome to: The design team IS NOT welcome to: these elements contradict what you write below * Second-guess maintainers or well-intentioned contributors. * Block development based on existing designs. * Block development based on incomplete or planned designs. * Veto development except in modules with branches that the design team maintains. * Be dismissive of other people's own approaches to design. * Dismiss or handwave requests for clarification about decisions taken. here: * Every decision is up for review. The state of the world changes, not everyone shares your assumptions, and matters which seem settled may need revision. so, if every decision is up for review, why shouldn't the people doing design second-guess or block? finally, and particularly, this is wrong: * Assume that no one but them does design that is good for Gnome. if you're designing for Gnome, then *by definition* you are on the Gnome design team. if your designs are in conflict with what other people doing design are trying to achieve, then you should talk to them, and revise them and/or achieve a rough consensus on what is the direction to take. by the way, since we're dropping rules by fiat, and given that at least I'm empowered by the fact of having been elected on the Foundation's board, I think people on this list are welcome to assume that people mean well, and are NOT welcome to assume conspiracies or assume that people do stuff just because. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ 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: Rules for design in Gnome
I would like to take a moment to make a reflection. Maintainers only get to decide what's done in their modules back then when GNOME was organized in a maintainer centric fashion. However with 3.0 we have moved towards a model where yet another force is included in the decision making process, that is, the design team. So far they have done a huge amount of good quality work, GNOME 3.0 wouldn't be what it is without them and without this approach. You don't find many open source communities where a pipeline for design driven development is implemented, in fact, very few companies implement this either. I think we should embrace this concept. I think giving ALL the decision making power to the maintainers is a bad idea, in fact I think it's harming to do so. I can certainly understand that it may be risky to do things that way, we may alienate and harm the motivation of some people, but maintainers, as much as I respect and praise them for the work they do, should understand that they are trust are deposited onto them by the community to follow the community process, and if the community decides that they may not have the final word on everything, that's the way it should be. I guess that all I am saying is just because we have been a maintainer/module centric development model doesn't mean we have to keep doing things that way, I want GNOME to be a design driven community, I think it's obvious what the benefits are by looking at the progress of GNOME Shell and the different applications that are being revamped by the design team. And I think that if we chose to, as a community, we can ask maintainers to trust the design team when it comes to design. Now, that doesn't mean that a maintainer cannot challenge a design decision, but in the same way that challenging a maintainers implementation takes patches and a great deal of technical discussions, maintainers will have to learn to speak de language of the design team, and that takes time. Of course, this design driven approach comes with a cost, and challenges may rise, but I think this should be a matter of consensus and discussion. I respect and I admire Federico, and I certainly understand why he is upset by some of the new problems that are arising. I think it would help a lot if the people involved in some of the problems he is experienced stepped up in a constructive and open manner, I think that most of the problem comes with the fact that some of the design members don't communicate much outside of certain circles. Yet, I don't think this thread had the best start in this regard :) Disclosure: I've worked closely with most of the design team during the Font Dialog development and the Planet GNOME redesign, they were open, friendly, and VERY helpful at all stages, but at the end they allowed me to make my own decisions. 2012/4/24 Seif Lotfy s...@lotfy.com OK first let us all please calm down (This does not apply to Emmanuele, since he seems always calm :P) We all have the best intentions at heart. I think Federico knows exactly that the design team has best intentions. And I hope the design team knows that Federico has the same intentions. This thread sums up and shows the communication flaws between the design team and some of us in the community. There must be a reason why this E-mail was sent and it is not to flame or anger people. We are discussing a problem here. We all agree that: - *No one is in charge. GNOME designers know they don't decide on behalf of GNOME.* - *We are trying to build a product here. * Yet how can we build a product if *some* developers don't feel attached to what they are contributing to. Should those leave the community just because they don't share the vision of the design team. If a designer designs a feature for an application, but the maintainer of the app does not like it, who will implement it? And the other way round we can not develop applications without designing them else no one will use them and we will lose a developer base. There is a perception that GNOME design team are the ones decided the direction. This perception did not come out of thin air and is not a conspiracy. It is a communication problem. From my observation I think the design team cares more about building the product and sometimes forgets about the community and the social capital of GNOME. This might be based on the fact that *most* of the designers are hired by companies. So if a maintainer doesn't want to implement their designs they can rely on the financial capital to make it happen. This leads to some *developers feeling helpless about how to influence the direction of GNOME* * * Also some designs of applications are not done, and mostly are a revamp of currently existing applications. Suggesting adding a feature to one of the applications is the considered invalid because they don't fit the future plans of the design (that might not be done). Can a developer add such a
Re: Rules for design in Gnome
On Tue, 2012-04-24 at 11:08 +0100, Emmanuele Bassi wrote: * Assume that no one but them does design that is good for Gnome. if you're designing for Gnome, then *by definition* you are on the Gnome design team. I designed the dynamic help menus. I don't think anybody thinks of me as being on the design team. If they did, they'd probably consult with me about things like removing menubars. I first discussed dynamic help menus in public at my GUADEC talk in 2010. I sent my initial patches for glib and gtk+ in April 2011, months before there was a public implementation allowing us to add stuff to the app menu. I blogged about it. I don't know how to make it any less of a secret. if your designs are in conflict with what other people doing design are trying to achieve, then you should talk to them, and revise them and/or achieve a rough consensus on what is the direction to take. If you remove menubars, you're drastically changing the way users access and interact with help. If you're changing the way help works, I firmly believe the onus is on you to talk to the people who work on the help. We're very easy to contact. We have both an IRC channel and a mailing list. by the way, since we're dropping rules by fiat, and given that at least I'm empowered by the fact of having been elected on the Foundation's board, I think people on this list are welcome to assume that people mean well, and are NOT welcome to assume conspiracies or assume that people do stuff just because. Nothing in Federico's email suggested that to me. He didn't name any names, nor any things anybody had done, nor any suspected reasons for why they had done those things. He just stated what he thinks ought to be the rules going forward. Granted, it was worded as a decree instead of a proposal. That was probably not the best way to write it. But the email was about as non-accusational as you can get while still conveying what you believe should be the rules. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
On Tue, 2012-04-24 at 10:54 +0100, Bastien Nocera wrote: I think an apology is in order. That would require criticizing somebody in an inappropriate way first. I don't see that here. However I would have appreciated if Federico had elaborated on the reasons and motivation for his post. andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
Em Tue, 2012-04-24 às 15:50 +0200, Andre Klapper escreveu: On Tue, 2012-04-24 at 10:54 +0100, Bastien Nocera wrote: I think an apology is in order. That would require criticizing somebody in an inappropriate way first. I don't see that here. I don't agree. I find it rude and out-of-order, and I'm pretty sure your response would be very different if people sent out a similar list about the bug squad. However I would have appreciated if Federico had elaborated on the reasons and motivation for his post. andre ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
On Tue, 2012-04-24 at 15:06 +0100, Bastien Nocera wrote: Em Tue, 2012-04-24 às 15:50 +0200, Andre Klapper escreveu: On Tue, 2012-04-24 at 10:54 +0100, Bastien Nocera wrote: I think an apology is in order. That would require criticizing somebody in an inappropriate way first. I don't see that here. I don't agree. I find it rude and out-of-order, and I'm pretty sure your response would be very different if people sent out a similar list about the bug squad. Hmm. If this was about the bugsquad I'd probably be highly confused and respond by Why did you send this; why do you think this is needed; and what problem do you see and try to solve by this? And these are the same questions that I have towards Federico now. andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
On Tue, 2012-04-24 at 10:54 +0100, Bastien Nocera wrote: Hello Federico, Em Mon, 2012-04-23 às 20:58 -0500, Federico Mena Quintero escreveu: snip From http://live.gnome.org/CodeOfConduct Assume people mean well Federico made no statements as to anybody's intentions or motivations. For reference, this is is what it looks like when you assume somebody doesn't mean well: Person X did Y wrong BECAUSE he/she is evil. This, however, is just a disagreement about what a person did: Person X did Y wrong. We have to be able to disagree with people's actions and to discuss those disagreements publicly. If we can't, our community dies. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
On Tue, 2012-04-24 at 10:58 -0400, Shaun McCance wrote: On Tue, 2012-04-24 at 10:54 +0100, Bastien Nocera wrote: Hello Federico, Em Mon, 2012-04-23 às 20:58 -0500, Federico Mena Quintero escreveu: snip From http://live.gnome.org/CodeOfConduct Assume people mean well Federico made no statements as to anybody's intentions or motivations. For reference, this is is what it looks like when you assume somebody doesn't mean well: Person X did Y wrong BECAUSE he/she is evil. This, however, is just a disagreement about what a person did: Person X did Y wrong. We have to be able to disagree with people's actions and to discuss those disagreements publicly. If we can't, our community dies. I'm sorry, but thinly veiled insults are still insults. --8-- From: Maître D' Subject: Spitting in the soup The kitchen staff IS NOT welcome to: * Spit in the soup --8-- I didn't say you spat in the soup Trying to hide the fact that Federico was venting for whatever reason isn't going to help keep this community any more healthy. FWIW, I'm not going to comment on the ludicrous demands being formulated until we hear from the person who started this thread. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
On Tue, 2012-04-24 at 16:11 +0100, Bastien Nocera wrote: On Tue, 2012-04-24 at 10:58 -0400, Shaun McCance wrote: On Tue, 2012-04-24 at 10:54 +0100, Bastien Nocera wrote: Hello Federico, Em Mon, 2012-04-23 às 20:58 -0500, Federico Mena Quintero escreveu: snip From http://live.gnome.org/CodeOfConduct Assume people mean well Federico made no statements as to anybody's intentions or motivations. For reference, this is is what it looks like when you assume somebody doesn't mean well: Person X did Y wrong BECAUSE he/she is evil. This, however, is just a disagreement about what a person did: Person X did Y wrong. We have to be able to disagree with people's actions and to discuss those disagreements publicly. If we can't, our community dies. I'm sorry, but thinly veiled insults are still insults. --8-- From: Maître D' Subject: Spitting in the soup The kitchen staff IS NOT welcome to: * Spit in the soup --8-- ^^^ Still not an insult. I didn't say you spat in the soup Federico didn't say this. I may have implied it in my email to Emmanuele. I'm sorry for that. I worded my response poorly. I stand by my assertion that you aren't NOT assuming somebody means well if you don't ascribe motivation. You can very well assume somebody has the best intentions at heart and still vehemently disagree with their actions. Trying to hide the fact that Federico was venting for whatever reason isn't going to help keep this community any more healthy. It's clear there is a non-negligible group of people who feel disenfranchised. Trying to hide that fact isn't going to help either. Whether or not anybody has done anything wrong, we have to figure out why people feel this way. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
On Tue, Apr 24, 2012 at 5:41 PM, Shaun McCance sha...@gnome.org wrote: On Tue, 2012-04-24 at 16:11 +0100, Bastien Nocera wrote: On Tue, 2012-04-24 at 10:58 -0400, Shaun McCance wrote: On Tue, 2012-04-24 at 10:54 +0100, Bastien Nocera wrote: Hello Federico, Em Mon, 2012-04-23 às 20:58 -0500, Federico Mena Quintero escreveu: snip From http://live.gnome.org/CodeOfConduct Assume people mean well Federico made no statements as to anybody's intentions or motivations. For reference, this is is what it looks like when you assume somebody doesn't mean well: Person X did Y wrong BECAUSE he/she is evil. This, however, is just a disagreement about what a person did: Person X did Y wrong. We have to be able to disagree with people's actions and to discuss those disagreements publicly. If we can't, our community dies. I'm sorry, but thinly veiled insults are still insults. --8-- From: Maître D' Subject: Spitting in the soup The kitchen staff IS NOT welcome to: * Spit in the soup --8-- ^^^ Still not an insult. I didn't say you spat in the soup Federico didn't say this. I may have implied it in my email to Emmanuele. I'm sorry for that. I worded my response poorly. I stand by my assertion that you aren't NOT assuming somebody means well if you don't ascribe motivation. You can very well assume somebody has the best intentions at heart and still vehemently disagree with their actions. Trying to hide the fact that Federico was venting for whatever reason isn't going to help keep this community any more healthy. It's clear there is a non-negligible group of people who feel disenfranchised. Trying to hide that fact isn't going to help either. Whether or not anybody has done anything wrong, we have to figure out why people feel this way. You hit the nail on the head. Ignoring a problem doesn't make it go away. Thank you for this -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
On Tue, 2012-04-24 at 16:11 +0100, Bastien Nocera wrote: --8-- From: Maître D' Subject: Spitting in the soup The kitchen staff IS NOT welcome to: * Spit in the soup --8-- I didn't say you spat in the soup Correct - nobody stated so far that anybody spat in the soup. As you already brought up Assume people mean well from GNOME's code of conduct in your initial response, this can also be applied to your own assumptions when you try to intrepret things between the lines. Plus even if the form of bringing up an important problem might sometimes be questionable, I still prefer this to not bringing up the problem at all. And there is a problem in the GNOME community. andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
On Tue, Apr 24, 2012 at 8:39 PM, Andre Klapper ak...@gmx.net wrote: On Tue, 2012-04-24 at 16:11 +0100, Bastien Nocera wrote: --8-- From: Maître D' Subject: Spitting in the soup The kitchen staff IS NOT welcome to: * Spit in the soup --8-- I didn't say you spat in the soup Correct - nobody stated so far that anybody spat in the soup. As you already brought up Assume people mean well from GNOME's code of conduct in your initial response, this can also be applied to your own assumptions when you try to intrepret things between the lines. Plus even if the form of bringing up an important problem might sometimes be questionable, I still prefer this to not bringing up the problem at all. And there is a problem in the GNOME community. Exactly. I couldn't agree more right now. Again the fact that this thread is came up means that there is a problem. And as we can see both designers and developers are not happy. Ignoring the problem, going offline to get work done or whatever, is not going to solve this problem. It will just make it worse. I think we first need to: 1) agree that there is a problem 2) figure out what he problem is 3) figure out how the problem was caused 4) agree that we want to solve this problem 5) find a way to solve the problem Cheers Seif andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper ___ 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
