On 02/29/2016 12:41 PM, fr33domlover wrote: > Hello, > > Some random notes below. > > On Fri, 26 Feb 2016 13:22:16 -0800 > Bryan Richter <br...@snowdrift.coop> wrote: > >> I want (re)start engineering-circle meetings. I'd like to brainstorm >> some meeting topics so we know what we'll be talking about. :) I'll >> kick things off with a (sorted) list of potential topics: >> >> - How/where to document code > > There are two ideas I like. When I write non trivial code, such as an > implementation of some algorithm or a non-obvious sequence of definitions, I > usually add comments right into the source. That's one thing. When bigger > concepts like entire APIs need docs, there are 2 nice approaches. One, put a > big doc comment for an entire module at the top of the source file. Two, do > what Linux and Git do: Have a doc directory with some text documents > explaining > parts of the system. I never used the latter because I either use the former > or > a separate wiki, just wanted to mention it's a nice idea. > >> - App architecture exploration >> - Roadblocks currently facing developers and designers > > Not critical, but: Understanding the components of the app. The "mechanism", > wiki, tickets, etc. Having an overview of them which also refers to some > source > files could help new devs find their way and find tasks they like to do. > >> - Bridging the gap between development roadmap (where we're going) >> with existing code (where we are) >> - Explore existing task backlog >> - Facilitating volunteer contribution >> - Breaking down the engineering circle >> - System architecture improvements > > Since Snowdrift is using email verification, what if we move from HashDB to > Account or Email? If it does what Snowdrift needs, it means you can remove a > lot of the auth related code and use what those auth plugins provide. > > Also, although not exactly related, I also saw some monadic forms which could > possibly become applicative forms. Not a big deal, but AForms are more > readable, easier to manage, easier to compose. Of course not all MForms can > become AForms, it requires a deeper look. > >> - Criteria for keeping, dropping, or rewriting existing components > > What are the goals of Snowdrift eventually? Does it /aim/ to provide wikis and > tickets and stuff like that? Or maybe provide them optionally (like Darcsden > where you can toggle issues, maybe other features too per repo) for small > projects which prefer a simple built-in solution that a separate full app? >
The primary aim was to have good tooling for ourselves without compromising our values… secondarily to make systems that weren't programmer-centric (i.e. having wiki pages that more people can participate with and not make tech skills a block to participation)… thirdly to make any work we do whether researching existing stuff or building new to be helpful to other projects… fourth and final, there are tons of advantages to integration where the connection of volunteering and feedback and communication to the same system as pledging would be the ideal. We would certainly want to be practical and let projects turn off features. In practice today, we're realizing that we need to put off too much stuff on these extraneous functions because we just don't have the resources to take it all on right now. > Things like wiki and tickets could be refactored into separate Yesod > subtsites. > This work can be done in parallel to core dev work. > Absolutely, we need those things stripped out into subsites and the sooner the better, work on that could be massively helpful. > By the way I'm working on a dev platform web app (like gitlab etc.) using > Yesod, so I could use such subsites there myself. And regardless, if I really > make progress there it means we'll have all those project features in a > dedicated app written in Haskell and Yesod, and having them separately inside > Snowdrift would be a bit of repetition eventually. > That certainly is, well, we'd rather focus on the core necessities to getting launched, but the idea of all our tooling integrating and being all in Haskell and easily integrated and all functional is a superb *dream* in the long-term.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list Dev@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/dev
