|Expected Behavior in the Lift community||David Pollak||5/10/11 2:33 PM|
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:
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:
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.
|Re: [Lift] Expected Behavior in the Lift community||Mads Hartmann Jensen||5/11/11 1:35 PM|
Created a Community page on the wiki where we can store these kind of things. So far there's a page for the loyal opposition, the expected behavior and the happy lift'r prize.
|Re: [Lift] Expected Behavior in the Lift community||David Pollak||5/12/11 2:06 PM|
On Wed, May 11, 2011 at 10:35 PM, Mads Hartmann Jensen <mad...@gmail.com> wrote:Hi,
Lift, the simply functional web framework http://liftweb.net