A top-level goal of the Lift community is to be a warm and welcoming place.  Helping people who invest their time and effort in Lift and build applications with Lift be successful is a core value in the community.  The Lift community is a place where the open exchange of ideas is very important.  I personally take the Lift culture very seriously.

As the Lift community grows, more and more people with more and more views, opinions, and perspective enter the community and enter the conversation.  Keeping the discussion a positive exchange of ideas and keeping the dialog open so that people are encouraged to ask questions and share their views requires a very delicate balance and the maintenance of a decorum in the community.

Firstly, it's important that the vast majority of discussions take place on the Lift Google Group.  The committers discuss design choices, etc. on the main mailing list so that the whole community can see how decisions are made.  This is why I actively discourage people from contacting me privately (except for zero-day security issues.)  This is also why we ask that people discuss issues on the mailing list before opening tickets and we redirect discussions from tickets back to the mailing list.  The discussion of the design choices in Lift should be available for everyone to see and available as a history of Lift in the Google Group.

If you are new to the Lift community, please approach the community is a polite and respectful way.  This means:

• If you identify deficiencies in the Lift wiki or other public documentation, please work to fix those deficiencies rather than complaining about them.  If you've got questions, we'll gladly answer them on the Lift list.  You are just as capable as anyone else at updating the wiki or writing a blog post about the issue.
• If Lift is not behaving as you expect, please ask questions about what you're seeing.  The ideal form of these questions is "When I do X, my Lift app does Y, but I expect it to do Z, why?"  This provides a set of language to discuss your application and the way that Lift responds to requests.  Perhaps there's a way of improving Lift.  Perhaps there's a concept that's different in Lift than you might be used to.  Perhaps there's a documentation issue that can help bridge the gap between what Lift is doing and what you expect it to do.  Most importantly, just because Lift is behaving differently than you expect it to, it's not necessarily a bug in Lift.  Starting off a discussion by claiming unexpected behavior is a bug sets the tone of the discussion to a negative one.  It's no different that responding to a post on the mailing list with RTFM or "you clearly don't understand" or some other statement that puts the poster on the defensive.
• Your priorities are necessarily different from the rest of the community's priorities.  If your post doesn't get answered immediately, please don't "bump" it or repeat it.  Somebody will most likely get to you when they can or if they have a solution to the post.  If you report an issue and the committers don't set a high priority on addressing the issue, being a squeaky wheel doesn't help (although being a production site does help a lot... if you've put Lift into production and you're facing a non-trivial issue, let us know and we will prioritize the issue up.)
• The person that addresses your question may ask you to post an example.  This has a very specific meaning (See https://www.assembla.com/wiki/show/liftweb/Posting_example_code)  This allows everyone to see the issue you're facing in running code.  This allows everyone to see the patch that solves the issue.
  

So, when you post, please follow these guidelines:

• Please say please and thank you.
• Wait for an answer.  If you haven't received an answer in a week, then, yes, you can ask if anyone has seen the issue or has an answer to your question.
  
• If you get an answer, please take the time to update the wiki or write a quick blog post about the question and answer and then post the link to your work on the Lift mailing list.
• If you know the answer to someone else's question, please help them out.
• When you're new in the community, please tread lightly.  The Lift community is likely different than other open source communities and learning about out community will help you get the most out of it while contributing to it.
  

With the above being said, I'll talk a little about priorities and how an individual's behavior can impact how much positive attention they get in the community.

By day, I am a very expensive consultant.  I also have more business than I can handle.  I am also a father, a husband of a woman with a very busy and successful lawyer, and a contributor to a number of physical communities that I'm associated with.  I also manage the Lift project, manage this community, contribute to this community, write code for Lift, manage the design of Lift, recruit new committers, and advocate for Scala and Lift (as well as writing some Scala and Lift related books and articles.)

The number of open Lift tickets is growing and the volume in this forum is growing.  Some of the long-term committers are taking time off to grow their families, so we're down a couple of seasoned hands.

So, bottom line is, I'm busy.  There's far more than I can do in the 18 or so hours I'm awake every day.  I must prioritize.

Next, let's talk about Lift.  Lift is good, but it's not perfect.  It's got bugs in it (both discovered and undiscovered.)  There are many, many improvements that we can make to Lift and a big part of how we choose to improve Lift (both bug fixes and feature adds) is based on supporting the kind of community we want to be part of.

Part of the calculus in my prioritization is how a particular person approaches the community.  If someone approaches the community in a polite manner and is offering to cooperate, give back, and be part of making Lift and the Lift community a great thing, that person will get more of my time.  I will feel happy about helping that person out rather than grumbling to myself, "gee, helping that complainer cost me $200/$500/$2000 in lost consulting."  I am also well aware that the cost of trying Lift and the cost of reporting a bug is real and significant to folks.  I do not view my calculus as a one-way street ("what's in it for me"), but rather a balance of my time with the time (and associated costs) for folks who are coming into the Lift community.  That is one of the reasons that stress the value of helping newbies and very, very, very rarely give an "RTFM" answer (although we will politely point folks to the appropriate documentation.)

I prioritize my contributions to Lift and the community based on the likelihood of a good outcome in terms of growing a solid community member, improving the Lift code quality and improving the documentation around Lift.  Dealing with fringe use cases (those that have not been reported in code that has not changed for more then 6 months) is not a priority for me if the person who is reporting the issue is demonstrating behavior that suggests that they will not be a good fit for the community.  There are plenty of other things I can be working on (and the same is true of others in the community.)

Put another way, if someone you didn't know came into your workplace, found a bug in your software, and started complaining that your software was buggy or unfit for use, would you (a) spend the weekend away from your family to fix the problem; (b) pay somebody else to fix the problem; or (c) suggest that the person put the bug report in your inbox and you'd get to it when you finished with your other priorities?

There are simple ways to express some of the things that folks have been expressing:

• Good: "Lift is not behaving the way that I expect it to.  When I do X, Lift does Y, but I expect it to do Z."  Bad: "Lift is buggy." "You don't really support X even though you claim to." "Lift has a design flaw." or "I contacted you privately because I didn't want to air dirty laundry about Lift on the public mailing list." (Note, that unexpected behaviors, bugs, performance problems and even security vulnerabilities are not dirty laundry, but a normal part of any complex piece of software and should be discussed on the public Lift list unless the security vulnerability could be exploited [a zero-day flaw], in which case I ask that you contact me privately so that we can fix the vulnerability before it can be exploited in the wild.)
• Good: "Lift does not meet my performance requirements."  Bad: "Lift isn't ready for production use."
• Good: "Can you help me understand the way this API should be used?"  Bad: "I've only been using Lift for a week, but I would get rid of Lift's DOM manipulation and replace it with String manipulation" or "The behavior this API that's used through the Lift code base should be changed because I don't like it."

Finally, I'd like to discuss the long term value of a civil polite community versus the short term value of someone being right about an improvement that could be made to Lift.  Taken in isolation, an individual instance of being right (right about a feature or a design or about an unexpected behavior being a bug) may have value if it is addressed.  But the cost of having a harsh community over the long term is that the loud, harsh, confrontational people are the ones who dominate.  When you have a community shaped by confrontation, over the long term, it's harder to get things done right.  It's harder for people with different perspectives to be heard because they will either not speak up at all or get shouted down.  I would rather lose harsh community members and keep the Lift community being nice than have the community dominated by the harsh even if some of them are "smart" because almost every innovation I can think of in Lift has been driven by a quiet voice planting a seed in the community that's led to radical improvements in Lift including the Designer Friendly stuff, the current REST support, Wizard, etc.

I hope this post along with the "Loyal Opposition" post makes very clear what kind of behavior is expected in the Lift community and the reasons that we prioritize behavior over substance.

In the past, I've been very critical of IntelliJ.  But I'm always willing to try things again...

At the Functional Programming Exchange in London, Jason Zaug was kind enough to install and configure IntelliJ 10.5 (an early access release) on my computer.  He installed the Scala plugin and did some chicken sacrificing over the keyboard and handing some configurations to optimize my Scala coding experience with IntelliJ.

I've spent nearly a week with IntelliJ.  I am currently working on a mixed Scala and Java project and navigating the Java class hierarchy is non-trivial, so having IntelliJ's code navigation tools as well as method name completion is a real time saver.

While I still don't like IntelliJ's keyboard layout (even it's mock Emacs key mode), IntelliJ's now a superior development environment for me.  It's better than Emacs with Ensime.  It's solid and reasonably quick (although, I do have the latest, fastest Intel i7 Sandy Bridge chips in my machine).

So, I officially recommend IntelliJ 10.5 and the Scala plugin for doing Scala coding.  The IntelliJ team has done a great job of making IntelliJ and the Scala plugin better and better.

And if I have to eat my hat to make up for past reviews of IntelliJ, I'll be happy to.

Rock on.