I've always disliked the expression "eating your own dog food", but it's a good principle when the use case fits the project, and I think Leo's a flexible enough tool that the primary principle behind my OP can be accomplished without too much trouble.
My central point is time and energy invested in the project documentation process should be in the direction of lowering the technical barriers for those *not* already bazaar-familiar developers to get involved. If one's already gone to the trouble of becoming part of the Leo documentation team, setting up the toolchain etc then surely they're familiar enough with where things are located that navigating to the node that needs fixing becomes a trivial matter. The barriers for this latter group is probably more a lack of motivation than technical issues, and rightly so, they've got more important and interesting things to work on. It's the group of people relatively new to Leo, in the first flush of enthusiasm getting to know the project at the lower level on-ramps of the learning curve - this is the group that IMO should be tapped - let's look at how to make use of Leo's openness and customizability to empower them. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To view this discussion on the web visit https://groups.google.com/d/msg/leo-editor/-/Tl8azXjiMigJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
