The book is out of print now but it looks like you can borrow it on archive.org: https://archive.org/details/celticknotwork0000bain/mode/2up
The book is out of print now but it looks like you can borrow it on archive.org: https://archive.org/details/celticknotwork0000bain/mode/2up
Once you understand and use this approach, you can figure out most other approaches you need to use.
At the simplest level:
A CBC agreement is a short written contract between leaders and reports. Ideally, person to person, but leader and team is fine too. It defines the objective, deliverables, dependencies, expectations, and outcomes (i.e., success criteria). Work doesn't start until all parties agree.
A journal of contracts is just the running log of those agreements. Think of it as the team/dept/org's public ledger, what was agreed, by whom, when, and why, and ideally the artifact captures the negotiations and tradeoffs made to arrive at the final agreement. Patterns show up quickly (who delivers, who misses, where scope creep hides). This makes performance reviews objective and enables meritocracy.
Okay, things change, and sometimes new info emerges: agreements aren't stone tablets. So, agreements might include predefined checkpoints or "if/then" clauses. Instead of pretending we never change, CBC forces us to renegotiate in daylight, with both sides explicit about the cost of changing.
What leaders commit to: clarity, timely decisions, and removing dependencies. If a leader misses their side, say they don't secure the promised resource or they blow their own deadline, that's a contract miss just like an IC failing to deliver code. Also, by signing the agreement, the leader is sayin,g "I agree with this plan/strategy." In CBC, credibility runs both ways.
It's early, and I'm still publishing examples and tooling. But the premise is simple: if you can't write it down, negotiate it, and sign it, it's not really a commitment, it's just vibes.
Also, no, it's not Waterfall, because it's more about documenting "expectations" and "outcomes" than about specifying particular work activities.
cc quag
I'm curious about it and your thinking on how to track things over time and see what has surprised us since we got started. It is useful to note down every time you (or your team) sets an expectation with someone (or another team) and then make sure you don't forget about that. It's also useful to be deliberate when setting expectations.
Having a public journal could well work for noting down when expectations are set and whenever there is a meeting of minds. I've found when tracking things like this that the amount of data can quickly grow to the point where you can no longer quickly and easily reason about it. The success seems to live and die on the data visualization or UI/UX.
A search in Google for "Collaborate by contract" gives three results, all from the same person, all in the last few weeks. Including this new article it's 1776 words in total on CBC. It doesn't seem to be real or something that has been tried out in an organization. It appears to be Al Newkirk's idea for a system that could work, but has not been tried.
Specifically, I'd like to see an example of a contract and who agrees to it; what the journal of contracts looks like; what happens when after an agreement everyone learns something that they didn't know when the agreements were made; what are the leaders committing to and what happens when they fail to deliver that?
Links found on CBC: https://www.alnewkirk.com/bidirectional-accountability/ https://www.alnewkirk.com/understanding-collaborate-by-contr... https://www.alnewkirk.com/maybe-its-time-to-change-the-way-w... https://www.reddit.com/r/productivity/comments/1n04s5z/comme...
The things you've listed out make me guess you want to write 2d or 3d image rendering software. Is that right?
If that's the case, there's no substitute for trying to recreate certain algorithms or curves using a language or tool that you're comfortable with. It'll help you build an intuition about how the mathematical object behaves and what problems it solves (and doesn't). All of these approaches were created to solve problems, understanding the theory of it doesn't quite get you there. If you don't have a good place to try out functions, I recommend https://thebookofshaders.com/05/ , https://www.desmos.com/calculator , or https://www.geogebra.org/calculator .
A good place to start is linear interpolation (lerp). It seems dead simple, but it's used extensively to blend two things together (say positions or colors) and the other things you listed are mostly fancier things built on top of linear interpolation.
https://en.wikipedia.org/wiki/Linear_interpolation
For bezier curves and surfaces here are some links I've collected over the years: https://ciechanow.ski/curves-and-surfaces/https://pomax.github.io/bezierinfo/https://blog.pkh.me/p/33-deconstructing-be%CC%81zier-curves....http://www.joshbarczak.com/blog/?p=730https://kynd.github.io/p5sketches/drawings.htmlhttps://raphlinus.github.io/graphics/curves/2019/12/23/flatt...
A final note: a lot of graphics math involves algebra. Algebra can be fun, but it also can be frustrating and tedious, particularly when you're working through something large and make a silly mistake and the result doesn't work. I suggest using sympy to rearrange equations or do substitutions and so on. It can seem like overkill but as soon as you save a few hours debugging it's worth it. It also does differentiation and integration for you along with simplifying equations.
https://docs.sympy.org/latest/tutorials/intro-tutorial/intro...
[1]: https://isss.temple.edu/faculty-staff-and-researchers/intern...
Downloading and installing applications by dragging them from the installer to the Applications folder works fine.
The reason is that I want to keep the services in a portable/distro-agnostic format and decoupled from the base system, so I'm not tied too much to a single distro and can manage them separately.
My understanding is that when using containers updating is an ordeal and you avoid the need my never exposing the services to the internet.