Communication is very important to the health of an open source community, and there are varying levels of communication between sending a quick note to the mailing list explaining your idea in 3-5 sentences and coming to the mailing list with a fully completed blueprint -- anything between those two extremes is still great. There are so many upsides to communicating before coding that IMO there is no reason not to provide any level of communication beforehand: - opportunity for collaboration (the more people involved in a change the better, gives contributors a chance to participate in things they're interested in) - new and different ideas (we can't know the needs of our users and various stakeholders without talking to them) - adaptation (the implementation may be too far gone to easily adapt to a new idea) - guidance (e.g. feasibility, recommended approaches) - information (users like to know what changes are coming, reviewers can be prepared for incoming PRs) - quality engineering (QA can start working on test plans in parallel with dev implementation) - planning/prioritizing (if we know X is coming maybe we should prioritize a complementary effort Y that will lead to a better overall outcome)
Here is a relevant blog post from Dave Cheney about this exact topic: https://dave.cheney.net/2019/02/18/talk-then-code An optional blueprint process would be a great way to increase communication and collaboration in the project, but that doesn't necessarily mean we can't write code first. IMO if we can start writing code to solve the problem, we can at least communicate what the problem is and our basic idea of how to solve it (the first two sections of the proposed blueprint template). Why not kick that out to the mailing list and let the feedback roll in before getting too deep into the implementation? Then we can all collaborate on the design, make it better, and implement it faster with less code churn. - Rawlin On Fri, Aug 16, 2019 at 11:21 AM Chris Lemmons <alfic...@gmail.com> wrote: > > > I do think large changes like this might be better first discussed and > > requirements understood before we write code. > > A phrase I like from another public community is "Rough Consensus and > Running Code" (IETF). The idea is that for a practical design, you > need a general agreement from the participants and the ability to > actually implement it. > > But sometimes you get rough consensus from running code and sometimes > you get running code from rough consensus. There is sometimes spirited > debate about which order is better, not unlike the one we're having. > It's clear from observation that both orders work, though. Sometimes, > you can get agreement about what ought to be done, but nobody to > implement it. And sometimes you get good implementations, but nobody > actually agrees on what should be done. > > I think different people work best in different ways. For many people, > it's hard to reason well about a problem that you don't have an > implementation of. The very process of reasoning toward a solution > produces code as an artefact thereof. Other people reason best in > prose, leaving implementation toward the end of the process. > > We believe in community over code, so I think we're probably on solid > ground if we just accept each person as they come. When people show up > with code, we can try to build consensus around it. When people show > up and build consensus, we can try to build code from it. > > There's a balance here, of course, since we don't want folks to spend > a lot of time building code when we can't build consensus around it. > And we don't really want to spend a lot of time building consensus > around something nobody can or will code. So there's some value in > ensuring that we can reasonably expect both code and consensus. > Contributors should generally be aware of this and at the end of the > day, it's our time to spend, so whatever works best for us is ours to > pick. (Of course, if we're working on someone else's dime, the > dime-provider might have an opinion. :) ) > > Personally, I tend to prefer code-first for small-to-medium changes, > because I don't like proposing something I haven't at least prototyped > into something useful. And I tend to prefer proposal first for > larger-scale changes, where the risk of no consensus is high and the > code investment is very high. But that's just how I manage my ideas, > others work differently. > > On Tue, Aug 13, 2019 at 11:44 AM Rawlin Peters <rawlin.pet...@gmail.com> > wrote: > > > > On Fri, Aug 2, 2019 at 4:28 PM Dave Neuman <neu...@apache.org> wrote: > > > I do think large changes like this might be better first discussed and > > > requirements understood before we write code. I realize that it's hard to > > > actually accomplish that with so many different opinions, but I do think > > > it's the right thing to do. Having discussions up front lets us think > > > through things as a group and in my experience often leads to a better > > > solution. > > > > +100 on this. Internally at Comcast some of us have been kicking > > around the idea of a blueprint design process, where the general idea > > is you: > > 1. get some initial feedback from a smaller set of stakeholders on > > requirements > > 2. given an initial set of requirements, fill out a blueprint template > > describing the problem, proposed solution and design, areas of impact, > > etc > > 3. open a PR of just your new blueprint and ask the community for input > > 4. any community stakeholders can provide feedback directly on the > > blueprint PR > > 5. once design feedback has been addressed, the blueprint PR is merged > > 6. implementation of the blueprint will begin > > > > This process basically gives all interested parties the ability to > > provide input on a design before the implementation begins, so that we > > can better address everyone's concerns and ideas. If there are certain > > trade-offs to be made as part of the design, those trade-offs would be > > agreed upon in the PR review and included in a section of the > > blueprint for posterity. > > > > There are multiple other advantages to the blueprint process as well, > > such as being a good starting point for user-facing documentation, a > > resource for QA to verify the feature against, and information about > > what's new in a release. > > > > Writing up a blueprint would be optional, of course, but my hope is > > that by doing it, the benefit of writing a blueprint first will speak > > for itself and encourage contributors to follow the process. > > > > If you're curious what a blueprint could look like, Jeremy and I have > > been pitching the idea here for feedback (it includes a template along > > with a couple examples of completed blueprints): > > https://github.com/ocket8888/trafficcontrol/pull/2 > > > > On Fri, Aug 9, 2019 at 3:45 PM Robert Butts <r...@apache.org> wrote: > > > > Architecture wise, I'm in favor of the traffic ops sending the specific > > > > configuration to the cache. Main reason is taking features like "DS > > > > *individual *automatic deployment" > > > > into account, where we would like to be able to control "which server > > > > get > > > > which configuration and when" - e.g. edge cache "A" can be assigned > > > > with a > > > > DS only after all its parents are aware of the DS. I believe that if the > > > > control of "what configuration is pulled" is in the hand of the cache, > > > > the > > > > complexity of the cfg distribution flow would increase and debug-ability > > > > would be very difficult. > > > > > > @nirs Those are valid points, and I don't want to steamroll over your > > > concerns. But on some level, I'm afraid our concerns are at odds, being > > > able to canary versus having a single config source. I have a couple ideas > > > how we might reconcile them. > > > > I don't think they necessarily have to be at odds. We could still have > > TO push the set of config data to the caches without having it push > > the actual config files themselves. The caches would then digest the > > config data and generate their own config files from that. We'd get > > both the ability to canary config generation and the ability to push > > data from TO to ORT instead of ORT polling TO for data. > > > > - Rawlin
