On November 4, 2015 9:14:12 PM EST, Aaron Wolf <[email protected]> wrote: > > >On 11/04/2015 04:56 PM, Bryan Richter wrote: >> My branch 'strip-mechanism' on my Gitlab repo >> ([email protected]:chreekat/snowdrift.git) now has all backend-y code >> related to the mechanism in one file: original/src/Mechanism.hs. >> >> It's not pretty right now. Everything in there was cut and pasted >from >> its original location. It lacks a clear and consistent API, and some >> of the code is straight-up broken — not to mention it still doesn't >> implement the new mechanism properly. >> >> At this point there are a few possible paths to take. >> >> 1. Begin cleaning up Mechanism.hs and designing a decent API. >> >> 2. Actually implement the mechanism. >> >> 3. Split the mechanism into a separate library. >> >> 4. Split out other components from the main project, like >> Notifications. >> >> I think the best thing for me to do is #4. If I don't, #1 will be >> harder and might need to be re-done later. >> >> #1 and #2 will probably be done in parallel. I think a lot of code >> will end up getting removed. >> >> #3 doesn't seem especially necessary yet. Plus, doing so would >> complicate issues like database access. I'm going to take it off the >> plan for now. >> >> IMPORTANT: Because of the nature of this change, merging it into >> master would break a lot of website functionality. But the truth is, >a >> lot of that functionality is broken anyway — just less visibly. >> >> This is more a question for the discuss@ list, I guess, but what do >> you think? Should I go ahead and "break" the website? The only loss >> will be UI/UX bugs related to the mechanism, and the cessation of >> payouts. >> > >Exciting to hear about the progress. I think it's *much* more important >that the site show changes, breakage, new things, etc. than that it be >stable. Here's what we *need* stable on the site: access to the wiki >pages, editing, commenting, ticket searching and sorting, discussion, >the establishment process… > >The fact that the mechanism is broken means it isn't giving people a >great impression anyway. I am *strongly* in favor of (actually *want* >to >see) the updates get to master sooner rather than later, but only as >long as no link just fails, no page is truly broken broken… i.e. show a >"broken for now, update in progress [DATE]" message which will give >people the sense that things are happening! So we want to be sure every >FIXME issue is presented on the front-end, and then we should merge and >deploy even…
Agreed in some ways. I when it comes to bugs, I VERY MUCH prefer the visible variety. That said, as a beta tester (or person who is interested in being involved but not in the thick of it), it's frustrating if much time passes without change, and can lead to a lack of engagement and people walking away. Overall I'm leaning towards the 'break it now' option, but I want to make sure that before you break things, there's a plan in motion to fix them. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ Dev mailing list [email protected] https://lists.snowdrift.coop/mailman/listinfo/dev
