status of PRFC process?

[Joshua hoblitt]

I received marketing email this morning about "Puppet Application
Orchestration". I'm guessing this is related to PRFC-6 and the recent
PR's for PUP-XXXXs that are not publicly accessible.

If this feature is indeed related to PRFC-6, the index page lists this
PRFC as being in "draft" status. Per PRFC-0, the approval process is
supposed to be draft -> posted -> submitted -> candidate -> funded ->
completed. I don't recall any discussion on this list other than the
issues that can up with "application" became a reserved word.

To be clear, I am not complaining about features being developed behind
closed doors. Rather, I'm wondering why the PRFC process was
[potentially] not followed for a major feature? Is there not enough
community engagement? Is it too slow? Is it a failed experiment at this
point?

-Josh

--

[Ryan Coleman]

Hi Josh. I'm glad we had a chance to chat briefly at PuppetConf but wanted to follow-up on the list as well. 

As you indicated, PRFC-6 was Luke's early thinking of what we recently announced as Puppet Application Orchestration. Our approach to building this wasn't a reflection of the PRFC process as much as it was an attempt to put forward a complete thought for how we see these ideas coming together to manage applications with the full set of services provided by Puppet Enterprise. For me, it's a starting point. Shortly after the release of PE 2015.3, we'll have the Puppet release out with the language extensions behind a feature flag and plan to provide tooling by early next year. As more information becomes available and you have a chance to get your hands on the product, I hope we can discuss what's working, what's not working and develop the next iterations on these ideas through the PRFC process. 

Regarding the publicly inaccessible PUP tickets, I was trying to avoid early confusion before anything had hit the Puppet repo and neglected to fix the situation as I got swept up by PuppetConf. I'll clean up the project next week, after brief PTO. Sorry about that.

 

[Eric Sorenson]

On Thu, 1 Oct 2015, Joshua hoblitt wrote:

> To be clear, I am not complaining about features being developed behind
> closed doors. Rather, I'm wondering why the PRFC process was
> [potentially] not followed for a major feature? Is there not enough
> community engagement? Is it too slow? Is it a failed experiment at this
> point?

Hi Josh. We talked about this in person at the contrib summit last week, but
let's keep the conversation going here.

Can we separate out the question of the app orchestrator specifically from the
general PRFC process question? I think Ryan addressed the first one, and FWIW
I reacted pretty strongly too one I realized there were private tickets
mentioned in public repos; this is something that Red Hat and Oracle do that
drives me absolutely insane and I'm going to try very hard to make sure that
doesn't happen any more.

So the question I want to talk about is whether the process is broken more
generally. I have to agree that something is wrong just based on the tiny
number of successes it's seen, but I'm really reluctant to just pack it and
say "welp, that was a failure". There are useful features that have been
improved through the process; even ideas that are proposed but ultimately not
implemented like the one about Status Messages
(https://groups.google.com/d/topic/puppet-dev/5QFelBbbAMw/discussion) meant
that everyone could engage in a design discussion *before* a bunch of
development work happened.

So to break it down further, I think there are a few problem areas.

1. Process too onerous - I tried in the last reboot effort to simplify the
writing prompt and the process itself down, but I'm totally open to the
idea that there's more simplification to be done. It's at:
https://github.com/puppetlabs/puppet-rfc/blob/master/prfc-0.prfc/prfc.md
and please feel free to comment / PR if there's stuff that doesn't make
sense.

2. Upkeep requires time commitment - Pruning the RFC index, keeping the
in-flight proposals moving forward or expiring them when the comment period
is up, commenting and advocating, all of these take time, and unless/until
we get a "flywheel" of momentum turning it really feels like an uphill
battle. Not sure what to do about this one ;(

3. PL-led developments don't follow the process - Fundamentally,
Puppet-the-company *has* to be able to develop features in order to stay
viable in the market. Some of that development will, out of competitive
necessity, be done secretly. But I think there are definitely more
projects that could be designed more openly. We need to build it into our
process more tightly and make sure that it's followed; this is like #2 with
the added complication that it has to make business sense to justify the
added effort of open-source design and development. Again, I don't have an
immediate answer here but (as they say) awareness of the problem is the
first step.

Maybe more? Anything I've missed or commentary on the above is welcome.

Eric Sorenson - eric.s...@puppetlabs.com - freenode #puppet: eric0
puppet platform // coffee // techno // bicycles