couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: Futon.Next
Date Sun, 28 Oct 2012 19:53:55 GMT
On Sun, Oct 28, 2012 at 11:28 PM, Octavian Damiean <mainerror@gmail.com> wrote:
> 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.

May we need to define roles and let people take what fits them to
define task groups e.g. developers, designers, testers etc? So each
group could focus on their tasks more easily and take those tools that
may help to solve project goals. For example, I'd proposed no less
way, but if I wouldn't write most part of styles and even wouldn't
take any part in design, but only in testing why my opinion have to be
seriously counted?


--
,,,^..^,,,


On Sun, Oct 28, 2012 at 11:28 PM, Octavian Damiean <mainerror@gmail.com> 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 <jan@apache.org> 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 <ryan.ramage@gmail.com> 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.
>>
>>

Mime
View raw message