[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Back to work with revised to-dos

On Mon, Aug 10, 2009 at 10:41:14AM +0200, Yaakov Nemoy wrote:
> The deliverable i want to see is the docs team using the results of
> Satya's work. The actual things that need to be implemented are
> depedent on what the docs team would like to see.

That makes sense.  If we've got a web-based wysiwyg DocBook editor
that can let me edit guides pulled from fedorahosted.org, that is
pretty good.  Edit can even be read-only from the SCM with write to
local copy or some kind of web-based cache for peer review.

The ability to commmit-back via Beacon is nice but probably not as
reasonable in the timeframes.  Considering each upstream DocBook-based
guide has its own SCM and submission policies, it doesn't make a lot
of sense to accomodate those until we know they are useful to people.

IMO, being able to edit and generate a patch against the upstream
original is a very big win.  Anything beyond that is icing on the
cake, that is, nice to have but not essential for initial iterations.

> There isn't much time left to GSoC, and i don't know how much time
> Satya will have to work on the project afterwards. I think the best
> thing to do is to get it working on Fedora Infrastructure as a working
> usable demo, so people can experiment with it and see if it meets our
> needs. Then, Satya should use her best judgement on how to spend the
> rest of the time.


I'll try to clear this up in the Trac ticket.

> As for actual deliverables, i'm not too picky, just as long as there
> is a tarball which is a bunch of patches or a git repo, or something
> that Google requires.

Hmm.  That is a reasonable interpretation but seems to miss the spirit
of the matter.  When I see a project with a goal of, "Web-based
wysiwyg DocBook editor for Fedora Docs," I presume there is going to
be a working instance of something at the end.

If all we had was a tarball + patches, we'd be far from a
working-to-use system.  For example, this is why the Beacon packaging
was suggested in the original proposal to begin ASAP -- so the package
would be available to Fedora Infrastructure for their build-out of the
"working instance of something."

In my GSoC experience, projects that focus on a working web service
(for example) with a minimum feature set are more successful than a
complete feature set in a tarball + patches.

I think that goal was clear to Satya and yourself, so this is just
further encouragement to keep it a high priority.

- Karsten
Karsten 'quaid' Wade, Community Gardener

Attachment: pgpU800KibyAE.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]