Re: [Snowy] Snowy Hackfest Proposal

[Brad Taylor <brad getcoded net>]

Hey,

First off, you rock Paul for getting this going!

On Aug 25, 2010, at 5:45 PM, Jeff Schroeder wrote:

> On Wed, Aug 25, 2010 at 1:08 PM, Sandy Armstrong
> <sanfordarmstrong gmail com> wrote:
>> On Wed, Aug 25, 2010 at 10:02 AM, Jeff Schroeder <jschroeder gnome org> wrote:
>>> Releasing Tomboy Online 1.0 requires:
>>>    - Some css / template love
>>>    - Banging out any openid bugs that we see in the error logs
>>>    - Properly fixing the innodb issues as snowy requires working transactions
>>> 
>>> I was thinking of initially making snowy a "read only tomboy note
>>> syncing / viewing / sharing platform". That keeps the feature set
>>> small and makes the release goal very attainable. Scope creep will
>>> bite us hard if we add too many ponies at first. After beta (and maybe
>>> pre-1.0) we can work on enabling the funcooker by default and editing
>>> notes from the webui, encryption, etc.
>> 
>> I completely agree with you, except that I don't think we have any
>> hackfest-warranting issues that are blocking a public beta.
>> 
>> The way I see it, we're only a couple of patches away from an
>> invite-only alpha, and the only thing *really* blocking a public beta
>> is confidence in our ability to handle so many users and their data.
>> 
>> If we're going to have a hackfest, we should be working towards some
>> big stuff (ponies), otherwise it's a waste of the Foundation's money
>> to get together.  If we're not confident that we can work on some
>> ponies in October, we should aim for a later date for the hackfest.
> 
> You are right. What major things do we want to work on for the hackfest then?
> 
> What is stopping us from enabling the funcooker other than server side
> editing not being supported. If thats it, I could work on editing. It
> can't be much harder than posting the new data, updating NoteInstance,
> and updating the user's sync guid more or less.

What Sandy said is accurate.  I stopped working on Funcooker mainly because the way each browser implements contentEditable is a different level of brokenness.  Any XSLT that we create to transform whatever wacky HTML the browsers cough up would be super super fragile, would have to evolve as browsers change, and would definitely break on a regular basis, causing data loss.  In short, it's a bucket of fail.

I think a better target would be to hook up and theme CKEditor (since it already handles all that BS).  It also appears to have a way to create a custom XML backend so that the editor could send direct tomboy XML to our backend. Pretty sexy stuff.

For a hackfest in October, I think I'd have a couple of priorities in mind:

 * Implement new design (meaning, we'd have a mockup done already, and just be in template/CSS land)
 * (Maybe) Implement a mobile theme
 * Implement note editing via CKEditor/whatever
 * Implement note sharing

If we had a group of people, I think we could operate in three different, independent streams and merge everything together at the end.

Thoughts?

-Brad