Re: Proposal for a simple plan Lassi Kortela 12 Jul 2019 21:39 UTC
> That's a good start. It lays out some high-level > goals without going into so much detail that the > implementers' freedom to act is impaired. > > Assuming that people like this outline, the next > important step is for each volunteer to declare > which concrete subgoals they plan to work on right > away. That will help reduce duplication of > effort, and it can be a morale booster to see that > other people are excited, too. We really do have different personalities :) To me, that's a heavyweight planning process - it didn't even occur to me that we could go into such detail. The way I see it, a natural split is at major software boundaries: - server (graphql server and metadata scrapers) - client 1 (web) - client 2 (e.g. emacs) - client 3 (e.g. repl or command line program) Dividing these into sub-items is wishful thinking at this stage, and mainly increases communication/planning costs. If more than one person works on one item, that's fine but the communication needs to be so nuanced and frequent that plans or todos do more harm than good. I just don't speak that language of detailed planning for creative projects. I've never seen any compelling evidence that it works. At work, we've always used very lightweight planning processes, and even those plans we mostly ignored. In small open source projects there's usually no definite plan. And yet things get done just fine. Once API and module boundaries have stabilized and we have e.g. 3 API clients and 3 metadata sources to prove it, then it will be easier to hand off individual modules. But when interfaces evolve constantly, delegating work slows things down. All of the problems that have been brought up in these threads - doing everything in pure Scheme, having a clear division of modules and responsibilities, involving new people - I would solve all of them simply by waiting a few months or talking things out informally. Are there concrete things that could go wrong _with the end result_ if we do things in this messy way we have done until now? If so, could we just address those concerns? If the only concern is that things will take a few months to stabilize, I don't see that as a problem, because realistically that's going to happen with any approach. Non-trivial creative work always takes time until the result stabilizes. As for onboarding new people, I would suggest that people simply say if they are particularly enthusiastic about working on something, and then we find a way for them to work on that. Enthusiasm is the best driver.