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.soren...@puppetlabs.com - freenode #puppet: eric0 puppet platform // coffee // techno // bicycles
