On Fri, Jun 19, 2015 at 05:38:52PM +0100, Tom Hacohen wrote: > On 19/06/15 17:16, Felipe Magno de Almeida wrote: > > On Fri, Jun 19, 2015 at 3:55 AM, Carsten Haitzler <[email protected]> > > wrote: > >> After some prodding we now have the following at the bottom of: > > > > Hello raster, > > > > [snip] > > > >> Any comments? > > > > I think the following in Boost policy is very useful to have and be > > used in the guidelines(Do a mental s/Boost/Enlightenment/): > > > > <snipet> > > * Guidelines for Effective Discussions > > > > Apply social engineering to prevent heated technical discussion from > > degenerating into a shouting match, and to actively encourage the > > cooperation upon which Boost depends. > > > > Questions help. If someone suggests something that you don't think > > will work, then replying with a question like "will that compile?" or > > "won't that fail to compile, or am I missing something?" is a lot > > smoother than "That's really stupid - it won't compile." Saying "that > > fails to compile for me, and seems to violate section n.n.n of the > > standard" would be yet another way to be firm without being abrasive. > > If most of the discussion has been code-free generalities, posting a > > bit of sample code can focus people on the practical issues. > > If most of the discussion has been in terms of specific code, try to > > talk a bit about hidden assumptions and generalities that may be > > preventing discussion closure. > > Taking a time-out is often effective. Just say: "Let me think about > > that for a day or two. Let's take a time-out to digest the discussion > > so far." > > </snipet> > > > > The "Questions help" really changes the mood of discussions and make > > for a more amicable and affectionate relationship between members. > > Hey, > > The efl community guidelines are intended to be short and simple. More > of a general way of thinking than actual specific ways of operation, so > I think the above guidelines are out of scope. >
I second this whole heartedly! Everything, if possible, including the code of conduct should be simple and sane. It's even trueer with a little a community, and, still feasable with a big one.--It's just a matter of choice to keep it simple and sane (KISS) while avoiding time waste on unecessary long guidelines that bore anybody to sleep when trying to read them. > Also, I don't really agree with their "question" method. I think posing > comments as questions you obviously think you know the answer to, is > more condescending (and fluffy) than just saying what you think. They > make it look otherwise by using a very biased example. The equivalent of > "that's really stupid - it won't compile" is "that's really stupid - > will it compile?". Without the negativity: "Doesn't look like it'll > compile" is in my point of view, better than "will it compile?". The key > I guess, is humility. > > -- > Tom. > I second this one as well, and this question of humility and being able to express oneself without unecessary verbiage and hypocrisy is *really* important. So, it's worth adding two points in the CoB to adress them. Anybody should be able to express oneselef freely. I mean anybody should be able to call crap code crap and stupid code stupid. I do understand that some people have ego issues and cannot stand being criticized, and, would take *any* critics *too* personally. As a human being, one should be open to criticism because this is the way to improvements as a worthy and likeable human being. One may not like criticism but it should not make anybody to enter into an endless and defensive (flame) war. Still, this has nothing to do with the discussion at hand, personnal criticism should be kept in personal exchange channels instead of being public to avoid dividing a whole community, because, in this case, everyone is assumed and pushed to take a position for or against one side or the other. We are talking about code criticism in order to be able to keep high standard with what is being pushed in our project here. Obviously, if fellow developers or users qualify a contribution as crap or stupid it's because they care about the project. If it's not obvious for you... First, do not obviously take "that's really stupid" or "that's really crap" as being directly aimed at your face--it's obviously about your code. And of course, you should be accountable for your contributions. Second, instead of show casing your ego by taking it as a personal attack, you'd better ask why if it's not obvious. Nobody ever came in this Earth by knwoing everthing! So, better ask why and learn a thing or two, instead of getting upset for nothing. I guess this is called humility. Of course, in this case, the commentator or critic should re-ajust the critics accordingly as needed. So yes, adding a point on humility and being able to express onself (free speach as such) is highly recommanded as practical guidelines. And please, keep keeping it simple and sane! Thanks Tom for this opportunity... because I was goind to re-read a whole Gentoo forums thread to (re-)find out those two important points. ------------------------------------------------------------------------------ _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
