With my operator hat on, my experience has taught me to consider user feedback very carefully. It is rare when users actually bother to report bugs. The majority of users tend to not report issues and then grumble about something being broken add just try and work around it. If it goes on long enough, they tend to find entirely different solutions, without ever telling you why you have an issue. Thus leading to your projects decline or even demise. So those users that actually report issues are great. They provide the opportunity to fix something before it is too late. So, its not that the silent majority doesnt care. They do. But tend not to be vocal. Those that do speakup don't tend to have many voices in and of themselves, but represent a great many other voices that don't tend to speak up. So few voices speaking doesn't mean your doing well and there are few real problems. Just that the feedback isn't happening with many voices. Just my $0.02. There may be other experiences out there. Thanks, Kevin ________________________________________ From: Chris Dent [cdent+os@anticdent.org] Sent: Wednesday, January 16, 2019 4:33 AM To: OpenStack-discuss@lists.openstack.org Subject: RE: [tc] [all] Please help verify the role of the TC On Tue, 15 Jan 2019, Fox, Kevin M wrote:
If its optional, then that might not happen properly. Delegating that authority might be a good solution as you suggest. But then delegation of prioritizing of reviews and other such things might need to go along with it at the same time to be effective? The idea is for there to be a flow of leadership from the TC to the project for some of the cross project work, but if that flow cant happen, then nothing really changed. Not so sure a delegate can have enough power to really be effective that way? Thoughts?
Delegation also simply spreads things around over a wider base, rather than addressing one of the core issues: there are too many things going on at once for there to be anything could be labeled a "unified direction". If we want (do we?) a unified direction, there have to be fewer directions. Positioning things as a "a delegate will do it" is a way of choosing to not limit the number of things being done. There are two competing voices around these issues, both have merit, but they remain in competition. One says: the role of the TC is to enable healthy contribution in all its many and diverse forms in the context of a community called OpenStack. Another says: the role of the TC is to help shape a product [1] called OpenStack. The first sounds rather positive: We're enabling lots of stuff, look at all the stuff! The second is often perceived as rather negative: That stuff could be so much better! None of these perceptions are complete or fully accurate, there are positives and negatives in all views, but what seems to come out of these conversations is that there are some very small and vocal minorities that care about these issues and have strong opinions, and everyone else doesn't care. Do they (you, silent readers!) not care, are they not interested, or is it a matter of "we've been over this before and nothing ever changes?" [1] I bristle at the term "product" because it sounds like we're trying to sell something. I'm thinking more in terms of "a thing that is being produced and has a purpose". -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent