<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jul 18, 2018 at 1:30 PM Paul Belanger <<a href="mailto:pabelanger@redhat.com">pabelanger@redhat.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'd actually like to hear more thoughts from the SF team here, so far we've only<br>
gotten TristanC and mhu.  Please take a moment and reply within the next week.<br></blockquote><div><br></div><div>I'm not part of SF team but I wanted to share some *personal* experience. It's a bit long but my TL;DR is "I see a lot of good things in this thread and I believe you're going into the right direction".</div><div><br></div><div>I've only seen good intentions in this thread and it's a pretty good sign that things will move on in the right direction.</div><div><br></div><div>I've been working on OSP (OpenStack productized by Red Hat) and things haven't been always green on our side...</div><div>I remember a few years ago when most of the repositories had a bunch of custom patches whereas now we are nearly close to zero for most of them (at least on the projects I'm working on now).</div><div><br></div><div>I also remember the reasons why we had these patches, and how we changed ourselves, please let me share it:</div><div><br></div><div>1) Most of the time a bug or a feature has to be fixed / implemented for "yesterday".</div><div>Deadlines are what they are, the only thing we can do sometimes is say "no, we can't do it for this release".</div><div>I believe over time we have improved on breaking down the features, prioritizing the bugs, so we could do a better job at planning, based on the capacity and the things that need to be done.</div><div><br></div><div>2) Downstream patches are expensive to maintain.</div><div>I've seen a bunch of times where people saying "It's quicker to prototype downstream, ship it and then figure out how upstream wants to do it".</div><div>(Note that I don't say SF is doing it right now, this is just an example related to this thread that I've experienced.)</div><div>By doing this way, it creates a technical debt to maintain (and only ourselves can maintain it since it's downstream), while things are being figured out upstream to see how this feature can be implemented. A waste of time and resources, just to ship something quick.</div><div><br></div><div>3) Upstream-only developers only are unicorns!</div><div>IMHO we can't be either downstream-only or upstream-only etc. We are building a product, based on Open-Source projects that we agreed to use and contributed to.</div><div>Our job is to make sure we can sell this product therefore bring the features into the projects that we use. It involves:</div><div>- Planning with Product Management (downstream mostly)</div><div>- Discussions, Design, Planning with the project team (upstream community)</div><div>- Implementation (upstream)</div><div>- Productization (packaging, containerization, custom testing, etc) (upstream + downstream)</div><div>- Ship to customers (downstream).</div><div>I've learnt that to work in a successful team, everyone in the team can be involved in these different areas and spread the load. I also believe that we are all able to wear different "hats" when it comes to doing X or Y to achieve a goal.</div><div><br></div><div>4) Knowledge is the key, share it.</div><div>Encourage individual mentoring, pair programming, collective bug triage, regular reviews/demos, etc. Share your knowledge with your co-workers, we should have SPOFs in the team, I think anyone is able to contribute when training happens.</div><div><br></div><div>I hope this was useful, at least I wanted to share that. Feel free to ignore this email though.</div><div><br></div><div>Good luck for your discussions and I sincerely hope you'll find ways to solve your problems, we all love Software Factory :-)</div><div>Cheers,</div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Emilien Macchi<br></div></div></div>