Unpleasant puppetlabs experience

[Philip Brown]

https://projects.puppetlabs.com/issues/14368#change-101086

Summary:

(We dont need to improve our public documentation, because people can go BUY documentation for puppet)

I can understand changing it to low priority or something.
But *Rejecting* this issue?
For a supposedly "free, open source" project? Really?

This does not motivate me to continue advocating for use of puppet, let alone developing for it.

[William Leese]

Seems to me more like:

After a year we still haven't found time for this. Let's keep our bug database manageable but only keeping the stuff we can do within a reasonable time or the bug reports that contain some troubleshooting effort we don't want to redo.

Quite a reasonable approach I'd say. With open bug databases, it's easy for the tool to lose it's value due to unmanageable backlogs.

[Felix Frank]

I do feel that Redmine's backlogging facilities leave much to be
desired, but I don't really agree with your conclusion.

I'm with Philip insofar that rejecting a bug is saying "won't fix" or
"not an issue anymore". Neither is apparently the case, so I consider
this at least a misuse of the tool.

I wouldn't go so far as to claim hostility towards the community. I
suggest re-opening the ticket and discussing the proper course of
action, i.e. perhaps adding the backlog keyword or similar.

Cheers,
Felix

[kaustubh chaudhari]

Hi,

I Agree with Philip and Felix!!

Some one might have implemented it with his own experience/try and error. But if its not documented, than its like re-inventing the wheel again and again!
Rejecting is not a solution, at least you can redirect to some other links where its used/fixed/configured, and say try this for now and we will look into it when we have time! :)

On the other hand i understand Seg/Developers are already loaded !!

-Kaustubh

[Felix Frank]

Not really. Seeing as this is a documentation header, there's only two
things you can do
a) write the docs yourself if you can or
b) wait for someone else to do so

[kaustubh chaudhari]

Hey,

Option a) is good!

Just curious, how do we submit the updated doc to Puppet Lab so that they can publish it on the website!

-Kaustubh

[Felix Frank]

https://github.com/puppetlabs/puppet-docs

[Christopher Wood]

(inline)

On Thu, Dec 05, 2013 at 05:35:13PM -0800, Philip Brown wrote:
> https://projects.puppetlabs.com/issues/14368#change-101086
>
> Summary:
>
> (We dont need to improve our public documentation, because people can go
> BUY documentation for puppet)
>
> I can understand changing it to low priority or something.
> But *Rejecting* this issue?
> For a supposedly "free, open source" project? Really?

I think we've tripped over the distinction between libre and gratis, wikipedia having a useful summary:

http://en.wikipedia.org/wiki/Gratis_versus_libre

Possibly consider all the work you've put into implementing puppet on your own systems, and consequently how obtaining puppet gratis doesn't mean that it's free of cost.

> This does not motivate me to continue advocating for use of puppet, let
> alone developing for it.
>

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> [1]https://groups.google.com/d/msgid/puppet-users/83b76366-d703-469f-a3fe-4b1fe8d28b58%40googlegroups.com.
> For more options, visit [2]https://groups.google.com/groups/opt_out.
>
> References
>
> Visible links
> 1. https://groups.google.com/d/msgid/puppet-users/83b76366-d703-469f-a3fe-4b1fe8d28b58%40googlegroups.com
> 2. https://groups.google.com/groups/opt_out

[Jerald Sheets]

Possibly consider all the work you've put into implementing puppet on your own systems, and consequently how obtaining puppet gratis doesn't mean that it's free of cost.

Please note that the exact same documentation is expected to be used for either and people spending crap-tons of money are expected to put up with the same issues.  This is not a licensed/open source argument.  This is a "do a better job of documentation" argument.

I shouldn't have to go hunt down other admins in my town to learn things with/from because none of us can make sense of the documentation...or its wrong... or it ignores systems or development best practices, or whatever your particular gripe may be.  

Puppet is the best there is, but it (and its docs) can be better. 

[xav]

On Fri, 2013-12-06 at 11:31 -0500, Jerald Sheets wrote:

> Please note that the exact same documentation is expected to be used
> for either and people spending crap-tons of money are expected to put
> up with the same issues. This is not a licensed/open source
> argument. This is a "do a better job of documentation" argument.
>
>
> I shouldn't have to go hunt down other admins in my town to learn
> things with/from because none of us can make sense of the
> documentation...or its wrong... or it ignores systems or development
> best practices, or whatever your particular gripe may be.
>
>
> Puppet is the best there is, but it (and its docs) can be better.

This feels like it's a very negative discussion and I wanted to
highlight my own experiences with Puppetlabs.

Puppetlabs make their money in part from their excellent additions to
the open source version (which makes deployment a bunch easier), but
also from paid support engagements - if someone wants to pay them to
update the docs for the open source parts, they will. If not then we
either wait for them to get the time to do so, or we submit a pull
request. We're not talking about a company the size of Google here,
Puppetlabs doesn't have large bunches of cash to throw around, and my
overall experience of the Puppet documentation has been excellent. The
particular page in the bug report was extremely helpful when I started
out with Puppet.

I'd be keen to see more examples and helpful tutorials, but that's not
core product documentation - the actual reference documentation on the
puppetlabs site is bang up to date, complete, and way beyond the level
of documentation available for many other products that sell for big
money. And even better, if that's not enough the source is very
readable and well commented.

There are several areas in the documentation where gaps exist, and I
commend Puppetlabs for highlighting these and over time filling them in.
The product is still in active development and over time just gets
better and better.

[Nick Fagerlund]

On Thursday, December 5, 2013 5:35:13 PM UTC-8, Philip Brown wrote:

Summary:

(We dont need to improve our public documentation, because people can go BUY documentation for puppet)

I can understand changing it to low priority or something.
But *Rejecting* this issue?

 Hi all, I'm the one who closed that ticket. Sorry, my bad.

First off, WE STILL PLAN TO IMPROVE THE TYPE AND PROVIDER DOCS. They can & should & will be better, and we don't consider the O'Reilly "Puppet Types and Providers" book to be an acceptable replacement for free documentation on our website.

That's going to take a big chunk of time, though, and we (the Puppet Labs docs team, hi) will have to schedule it as planned work.

Anyway, here's what happened with that ticket:

• We're moving ticketing systems. The new one will be publicly visible at tickets.puppetlabs.com in a matter of days.
• The docs team is already tracking work in the new system. We are not tracking ANY work in Redmine. The stuff in Redmine is old and out of date.
• So now I have to do a mass cleanup on the old stuff in Redmine in preparation for the complete switch-over.
• Some things I'm fixing now, some things I'm making new tickets for, some things aren't relevant anymore, and some things are so well-known in my team that we don't really need a ticket as a reminder; instead, we'll be hashing them out in our planning sessions once we've dealt with the stuff we're currently working on (at which point they'll turn into like a dozen related tickets). "Overhaul the type/provider docs" is in that last group.
• I marked some tickets as "rejected" that I should have marked as "closed." (Since we're still planning to do the work, but we aren't tracking it in that Redmine ticket anymore.) Sorry!
  
• On some of those, I also made a note or two about related developments that may have changed the relative priority of the issue. (In this case, the fact that there's a good reference *somewhere* out there means we have a small bit of breathing room, even though we still need to improve our version.)
• I *should* have also pasted in some boilerplate about WHY I was closing 50 tickets at once, and what to do if you were following one of them.

So yeah, sorry for implying we weren't going to improve type/provider docs; that's not what I was trying to say at all. Closing that ticket was about housekeeping, not about rejecting the work it represented. There will be a bit of an awkward stage as we switch ticketing systems; sorry about that, and thank you for staying vocal about what needs work.

NF

[Fred Lifton]

As a member of the Puppet Labs docs team, I would like to second what Nick said. We are a small team with a big backlog and we could not get our jobs done if it were not for the engagement and and assiduousness of our users. Thanks for your help and your patience.

As we grow the team and move ahead, I'll look forward to getting your comments and feedback.

Fred Lifton

[Felix Frank]

Hi xav,

very good reply, and I'd like to second the notion that puppet is indeed
an impressive example of open source software, especially wrt. the
quality of its documentation.

On 12/06/2013 10:11 PM, xav wrote:
> I'd be keen to see more examples and helpful tutorials, but that's not
> core product documentation - the actual reference documentation on the
> puppetlabs site is bang up to date, complete, and way beyond the level
> of documentation available for many other products that sell for big
> money. And even better, if that's not enough the source is very
> readable and well commented.

Again, good point, but I have to differ on the last bit. Close to the
core (the type/provider subsystem being a good example), it can become
daunting to grasp the ideas from reading only code and comments - for me
at least.

That being said, the team has been and is making a valiant effort to
improve the in-code documentation and the progress there is outstanding
as well.

Cheers,
Felix

[Nikola Petrov]

Exactly my thoughts on the subject. Basically if you don't like the
documentation you can research the problem(in this case custom
providers) and then just populate the missing gaps in the documentation.
This is how most of the open source projects out there improve their
documentation. If for some reason your pull request is REJECTED then
this is a different topic and is one I will be mad about(if at all
possible)

The fact is that the puppet project has one of the best documentations I
have seen out there. Maybe it's just me but I find my around REALLY FAST
these days.

--
Nikola

>
> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1386364284.6023.33.camel%40debian.my.home.
> For more options, visit https://groups.google.com/groups/opt_out.