Lassi Kortela <xxxxxx@lassi.io> writes:

| 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 didn't ask anyone to divide those into
sub-items.  Just pick tasks, at whatever level,
and let people know.  You proposed a bunch of
high-level tasks, and I suggested that people who
wanted to work on each thing speak up.

| 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.

Yes, absolutely.  Volunteers might not step
forward because they don't want to step on someone
else's toes by duplicating their efforts, but
can't even find out what they're working on so as
to pick a different project.

| 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.

Yes, exactly.  All I'm suggesting is that people
say what they plan to work on so that others will
know.  I don't know how to be clearer that I'm not
suggesting fine-grained planning.