I think it's fine, and desirable even, to hash out a technical plan. But there is a fine line between that and stymying progress through objection. Ultimately, whoever implements it makes the final call, and I would hate for them to feel like they have to please everyone. As a project, we have experienced problems in the past, with features being blocked because someone disliked X or Y decision. Let's try to avoid that.
It sounds to me like there's one or more Cloudant folks wanting to take the lead, and a few community members who want to assist. I'd say it probably makes sense for you guys to form a team and knock this one out of the park together. Have you had a kick-off meeting yet? On 28 October 2012 19:28, Octavian Damiean <[email protected]> wrote: > While I agree that we should make use of this momentum to get something > done I don't quite agree on the "let's jump right into it and use whatever > one thinks" approach. > > If we plan to use technology X to build it, then technology Y might be a > dependency. Less for example is a dependency of Bootstrap (unless we want > the default Bootstrap design). > > Same goes for the underlying framework, replacing Sammy.js with Backbone.js > is not just like replacing the JavaScript files it comes close to a > complete rewrite. > > Also, having multiple people work on the same project requires them to > reach a consensus on what they use to they can actually plug it together in > the end, it's not like everyone can develop their part in isolation and > everything will just work eventually. > > On Sun, Oct 28, 2012 at 5:51 PM, Jan Lehnardt <[email protected]> wrote: > > > Summing up: > > > > We have some momentum going here, let’s use it and roll! > > > > I suggest whoever ends up writing the CSS gets to choose > > whether they like plain CSS or a preprocessor. Same for > > all other build-utilities. If one of them ends up being > > an issue, we can rip them out later. I prefer to have a > > Futon.Next that we need to rip something out of for the > > long term than not having a Futon.Next for the long term. > > > > I’m so looking forward to see some results here soon! :) > > > > If whoever ends up working on this needs anything, please > > let me/us know. Very happy to help with any roadblocks. > > > > Cheers > > Jan > > -- > > > > > > > > > > On Oct 25, 2012, at 22:03 , Ryan Ramage <[email protected]> wrote: > > > > >> You misunderstood that requirement. If we're not using a feature (e.g. > > config) it won't get deployed anywhere, it'll be removed at build time. > > It's not a user facing optional thing, the code just won't be on our CDN. > > >> > > > > > > Ok, interesting. Good to know. > > > > > > > > >> Right, and there are ~10 that exist and approximately interoperate > > today. > > > > > > Haha. With the new ability of attachment first design of erica your > > > normal web style folders are couchapps. One can push futon in its > > > current form, with no modifications*. We could be done with the new > > > futon as well. > > > > > > * ok, one modification. Couch does not like attachments with _ > > > starting, which current futon has. We can make a conscious decision to > > > not do that. > > > > > -- NS
