On Sat, Jan 11, 2014 at 1:44 PM, Jonathan S. Shapiro <[email protected]> wrote: > ... It > takes someone with the ability to read precisely, serious determination, and > iron discipline.
And stamina! as a victim of programming-language designers' repeated efforts to re-invent Lisp [1] it is like watching football without (fully) knowing the game, the football is type-theory. The naïve observer may understand the football as an object, but can't decipher why it has to move around the field so much. Some of the type theoretic discussions would be more accessible if grounded with even trivial examples that contrast the core dilemma being considered. Or perhaps new discussions include a link to a introductory exposition. [1] I'm mostly joking, but want to comment on Clojure separately. > So the first thing I want to say here is: don't let intimidation hold you > back. Dive in! Thanks for the encouragement. > Curating: We have very useful discussions on the mailing lists, and we > arrive at useful conclusions. I'm glad this was listed first as I think most projects continually fail to do this, particularly capturing the collective refinement of understanding built up via the discussions in mailing lists. Cap-talk (to name one that most here will be familiar) needs this quite badly as it is not a mainstream idea (despite recent traction) so it doesn't get the benefit od the best workable ideas being continually retold and becoming woven into the security landscape. How various wins/criticisms of o-cap have been addressed on the mailing list are only discoverable by trawling back through hundreds of threads, slowly piecing it back together and trying to keep the story straight along the way. A collaborative wiki that could provide levels of explanation would help me find a pathway into the more esoteric topics. > Site administration: it would be a big help, and not all that much work, if > someone could deal with accepting new user requests and so forth. I'm willing to help with this, once a CMS is chosen. > Site architecture: > Site customization. I hope a CMS-poweruser could be recruited who has these answers at their finger-tips and is wedded to some solution they're willing to make work; personally I've (lightly) used them all, they all suck, just differently. I would suggest virtualisation and use of regular snapshots to save state (just in case it is breached by a bot). > Musings: It would be kind of nice if we had a place for people to gather > articles about what they want vs. what BitC actually gives them. What's > done, what's missing, and what found a solution that wasn't perhaps the > solution that you originally hoped for. This could be assisted with a regularly (or sporadic? [2]) posted work-plan and progress/status update, what has been done, what remains, what has been deferred, with sub-tasks highlighted for contributors to explore perhaps as path-finders (re-reading this I suppose I'm advocating a 'roadmap'). Tying this back to curation above suggests that some topics would benefit from a wiki-like page with problem definition, cherry-picked discussion, results and the winner picked (hopefully, or otherwise an unresolved/needs-more-work status). [2] not wanting this to be onerous but either frequent light-weight updates or irregular comprehensive updates, I'm not sure which would be more useful. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
