While I understand and respect the importance of focussing discussions to the making of things, surely there is more to a community communication substrate than this sole category of topic.
Do these guidelines, therefore, attempt preclude threads such as the discussion on the possible impact of new technologies (i.e. Dart), constructive discussions on development practices (i.e. REPL-driven-dev vs TDD), links to newly discovered external resources (i.e. new presentations/slidedecks) and general positive opinion "Wow, that was cool! Thanks so much for making that :-)" Perhaps much of this discussion would be better moved to the comments of external blogs? Still, it feels to me that the ability to constructively express and communicate *positive* opinion is a powerful source of energy which can cultivate enthusiasm and a general positive attitude within any community. I feel that because we're a technical community means we should be spending more care and effort fostering these social elements rather than trying to suppress/eradicate them. Sam --- http://sam.aaron.name On 15 Oct 2011, at 19:02, Rich Hickey wrote: > This is just a reminder. While in general our communication here is very > good, occasionally it goes astray. > > These mailing lists are run by, and for, people who make things. Most > messages should have one of these forms: > > I made something - here is my contribution > I am trying to use the thing someone made and am having trouble, please help. > I can help you with that thing someone made. > I am trying to make something and am having trouble, please help. > I can help you make something. > > They are not the place for opinion pieces and diatribes. > > They are not the place for advocacy about what 'ought' to be made. If you > think something ought to be made, then make it. Otherwise, respect others > peoples' right to choose what they do with their time. > > Occasionally, there may be disagreements about how something has been, or > will be, made. These disagreements should take the form of technical > arguments. To make a technical argument that gets (and gives!) respect: > > Keep it short > Stick to the facts > Use logic > Leave people out of it > Avoid rhetorical devices: > Superfluous or opinion-laden adjectives > Claims to speak for the community, or that everyone agrees with you. > Threats of what will happen unless things go your way > Any flavor of 'the sky is falling' > > If you are not the one making something, you should restrict your input to > very short technical arguments supporting your position. If someone has > already made your point, just +1 it. > > Please keep your posts short. > > Ignoring these guidelines fails to respect the time and effort of people who > make things, which you should care about if you intend to be one. > > Thanks, > > Rich > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
