Hello,
I apologise for the inactivity for the past few days. I am now in Pune and finished the initial procedures for joining RH. I can work regularly from now. I will start off with the revised to-dos starting from getting beacon in fedora. I just had a discussion with Nandeep about making having beacon in fedora priority #1. He agreed too in his mail of which I am pasting a snippet here (with his permission) to give you an idea of what will be up on his agenda.
So far the idea is to have me concentrate on getting beacon integrated with FAS, Zikula etc. while he works on core beacon improvements and adds more features to make it really usable.
"So after lots of people jumping in and out of this project and lukewarm response, I think the best way to roll this out is as a standalone product firmly deployed somewhere. For a proper end user product which users can employ to their benefits we need a cloud set-up pretty much like what Google Docs has to offer. For this I can think of the following core features that are absolutely essential for a release (these are technical mostly):
1. Copy paste handling to prevent crappy HTML generation. 2. Revision history and being able to revert back to other revisions 3. Undo redo stack 4. Be able to add media like pictures. 5. File browser for documents 6. Directly related to above point: an account system like Google Docs so per user cloud can exist. (For your Fedora system as mentioned, it can be FAS) 7. Be able to download the file in various formats (publican, you already have some work done on it).
Now we have to decide how much of this to implement within your GSoC period or whatever it is that your revised schedule allows."
The last line also made me wonder if my deliverables for GSoC have changed. It would be very convenient for me to know what is my to-do from GSoC perspective. I am not limiting this project till SoC and will make sure I work on it till it is in production use but knowing what is expected for SoC can help me order the tasks accordingly.
Regards, Satya
On Tue, Aug 4, 2009 at 4:50 PM, satya komaragirisatya.komaragiri@gmail.com wrote:
The last line also made me wonder if my deliverables for GSoC have changed. It would be very convenient for me to know what is my to-do from GSoC perspective. I am not limiting this project till SoC and will make sure I work on it till it is in production use but knowing what is expected for SoC can help me order the tasks accordingly.
I would think that the scope of work as part of your GSoC and, the scope of work beyond GSoC is something that should be worked out between your mentor and, yourself. I am tempted to say that the list of points (just above the paragraph I quoted) does make a significant difference to the functionality, however, whether you want to do it as part of your GSoC or, would like to continue rolling them up into scheduled releases is something one should leave to your sound judgement.
2009/8/9 sankarshan foss.mailinglists@gmail.com:
On Tue, Aug 4, 2009 at 4:50 PM, satya komaragirisatya.komaragiri@gmail.com wrote:
The last line also made me wonder if my deliverables for GSoC have changed. It would be very convenient for me to know what is my to-do from GSoC perspective. I am not limiting this project till SoC and will make sure I work on it till it is in production use but knowing what is expected for SoC can help me order the tasks accordingly.
I would think that the scope of work as part of your GSoC and, the scope of work beyond GSoC is something that should be worked out between your mentor and, yourself. I am tempted to say that the list of points (just above the paragraph I quoted) does make a significant difference to the functionality, however, whether you want to do it as part of your GSoC or, would like to continue rolling them up into scheduled releases is something one should leave to your sound judgement.
Just my comments, as the mentor.
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.
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.
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.
-Yaakov
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.
+1
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
On Tue, Aug 11, 2009 at 3:15 AM, Karsten Wadekwade@redhat.com wrote:
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.
I'd suggest a somewhat interim (and, fairly quick) blog post around the following bits:
- what is currently available - what is projected to be available within the GSoC timeline - what could be available beyond GSoC timeline * more in terms of a roadmap
The above should provide a guidance on what the Docs team can expect in terms of functionality and, whether the project would be in a consumption-ready state.
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.
I'd love to have a "test" instance set up that actually allows anyone to see how things are.
/sankarshan
2009/8/10 Karsten Wade kwade@redhat.com:
On Mon, Aug 10, 2009 at 10:41:14AM +0200, Yaakov Nemoy wrote:
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.
Let me clear this up. That's what Satya needs to deliver to Google in order to get paid. In order for me to pass her though, i want to see something working, namely a demo online that people are evaluating.
-Yaakov