README: Solving the "user" problem.
Gregory Brown
For the last two years, I have stated that I expect Prawn to have no
"users" before 1.0, meaning that our official policy is to only cater to
experienced (or at least highly motivated) Rubyists looking to help with
development in some way, either by reporting bugs, testing code on edge,
contributing patches, or other things that support the project.
But I will be the first to recognize that the above policy sounded a lot
more reasonable in April of 2008 than it does in February of 2010. It
has created unnecessary tension between our developers/contributors, and
Prawn users, and I am the one who is most guilty for being unforgiving
with this policy.
While Prawn is not "production ready" in the eyes of its developers, and
will continue to change rapidly between now and 1.0, we could take some
measures to make it so that end users feel welcome in our community.
The first of those steps is to take a different approach to how we deal
with development discussion than what we take with user support
questions and other general discussion topics.
== Tagging development discussions
I am proposing that we prepend the subject tag [dev] to questions that
have to do with Prawn's development. These are pretty much any question
that has to do with how Prawn is built rather than how it is used,
including discussion of potential defects, code review of patches, etc.
The assumption is that if you know to include the [dev] tag in your
subject, you will also know our conventions pretty well, or at least
respond well to constructive feedback about how we run our project.
== End user discussions
I will be sure to read every [dev] email that comes through the list,
but may leave many of the general questions for our users to answer, or
for the other core devs to respond to. If I do respond to non-dev
responses, I can promise to be a bit more patient than I have been in
the past.
End users will still be expected to be kind to one another, and we
strongly encourage folks to post clear, concise, runnable code examples
to show problems rather than describe them. But beyond that, we won't
stack a ton of expectations about skill level and knowledge of our
project's culture on new posters.
Over time, we can write up some documentation on what Prawn's
development cycle is like, and what our cultural values and conventions
are. But until then, I think the simple addition of a [dev] subject tag
should set us in the right direction.
So, unless there are strong objections, please start using this
convention in new posts, and let's hope that it puts us one step closer
to being able to serve a community that is far more diverse than I
initially anticipated it would become.
-greg
Chris Schumann
<gregor...@letterboxes.org> wrote:
> I am proposing that we prepend the subject tag [dev] to questions that
> have to do with Prawn's development.
I think that's a more inclusive solution than making separate [dev]
and [user] mailing lists. Excellent idea.
Chris
Gregory Brown
Yes, I've gone down that road before (with Ruport) and while it has its
benefits, the separation and the stigma that comes with two separate
lists is substantial.
Hopefully this will keep us together without requiring me to insist on
uniform acceptance of "The Way of the Majestic Sea Creature" from folks
who are just looking for a little help getting their job done.
-greg
Brad Ediger
While I would certainly advise others to exercise caution in using
Prawn in production, the reality is that I have several production
applications myself that depend on Prawn, and I'm sure the other core
devs do as well. We don't guarantee production-grade release
stability, especially given our fast-flux API, but I feel comfortable
saying that in terms of features, Prawn is a production-grade PDF
library. The influx of "end users" on this list seems to confirm this
observation. It's a problem of success, if anything.
> I am proposing that we prepend the subject tag [dev] to questions that
> have to do with Prawn's development. These are pretty much any question
> that has to do with how Prawn is built rather than how it is used,
> including discussion of potential defects, code review of patches, etc.
I think this is a great idea. It prevents fragmentation of the
community, and Ruby is a low-enough-ceremony language that users can
benefit from developer discussions too.
Brad
Gregory Brown
> On Fri, Feb 19, 2010 at 3:37 PM, Gregory Brown
> <gregor...@letterboxes.org> wrote:
>> While Prawn is not "production ready" in the eyes of its developers
>
> While I would certainly advise others to exercise caution in using
> Prawn in production, the reality is that I have several production
> applications myself that depend on Prawn, and I'm sure the other core
> devs do as well. We don't guarantee production-grade release
> stability, especially given our fast-flux API, but I feel comfortable
> saying that in terms of features, Prawn is a production-grade PDF
> library. The influx of "end users" on this list seems to confirm this
> observation. It's a problem of success, if anything.
It's absolutely a problem of success. Our 0.4 release is more stable and
documented than many Ruby libraries who are long past 1.0. I've also
had Prawn in production apps for a long time now, and many folks on this
list do as well.
But really, by 1.0 we should have an extension API and a core API that
does not break API compatibility until 2.x except to correct major
design flaws. We're not there yet.
Everyone else probably has a higher opinion of Prawn than I do. Such is
life, I suppose. Once we've removed all of my code, I might agree :)
-greg