Hi Steven,

I've been reading through some of the docs on your inkboard site. Very impressive, you guys are really doing some interesting work.

For your VisionDocument, section 7.3 on Installation, one comment that you could add to that system is that for Inkscape we tend to be very circumspect about adding new dependencies, and that new dependencies that inkboard would add would require an availability analysis. I.e., are the dependnencies things that are commonly available already on typical Linux distros, the Windows Gtk package, etc.

For these reasons, you may want to add a section that lists each of the dependencies that would need to be added to Inkscape, and include an analysis of how commonly available those are on Inkscape's target platforms. The reason for this is that if Inkboard features require a unique dependency (such as a jabber library) not already in Inkscape, there is a tradeoff between whether the addition of that library (and the work imposed on users who wish to install inkscape) is worth the value of the feature.

If there are no new dependencies required, then that's great - just state that fact and you're done.

Another option this section could consider is packaging of the inkboard functionality as a separate module. This would be more complex from a packaging standpoint, and would require users to install two separate things, but has the advantage of allowing users interested in using inkboard to have it, while others can avoid having to install the required dependencies if they do not require it.

In SupplementalSpecifications.pdf there is a blank in section 8.1 Documentation format. For Inkscape, the requirements for documentation is: Code documentation is done using Doxygen format. User Manuals are written as SVG in Inkscape itself, and are done in a 'tutorial' style; see /usr/local/share/inkscape/tutorials/ for examples and templates. Possibly, you may also want to include a blurb about this in the Inkscape man page. This is the inkscape.pod file in the root directory.

In 11.2 'Jabber liscence' should be 'Jabber license'

In section 14. Internationalization and Localization, I would encourage you to use the Gtk internationalization feature. It's pretty simple: Include the gtk/i18n.h header, and anywhere you have hardcoded strings that get printed to the user (such as dialogs, statusbar msgs, etc.) simply surround the string with _(). I.e., printf(_("You are now connected to %s\n"), host);

In your TestPlan, in section 5. Approach, add a section 5.6 Open Testing. Traditionally, you'll learn that there are several formal mechanisms for how to go about testing code in the proprietary world that are well thought out and tend to work fairly well, such as the ones that you list. But oddly, it's been found that Open Source can be just as stable and functional as proprietary software, without using *any* of these systematic approaches! The reason for this is simple: In proprietary software, you typically have a single release that is provided to the customer once, at point-of-sale, at which time the software must be nearly perfect.

However, Open Source follows a different developer-user paradigm, where interim releases are continually released to users, and incrementally improved as they go. This provides Open Source projects with a new, built-in quality assurance mechanism, which is aggressively iterative. Since you're not asking the user to pay you, this gives you a strong advantage in that you can release early on in your development process, gain whatever feedback you can, and continue making frequent releases to fix any bugs the community reports and to gain immediate feedback from users on features you implement. If you look at this as a 'testing methodology', it has the benefit of being highly distributable, it taps in a LOT of resources that you may not have time/budget to do alone in traditional structured testing, and due to the 'many eyes' effect, lots of bugs can be found more swiftly.

(FWIW, I'm in the testing department of the Open Source Development Labs, where we try to provide traditional style testing for open source projects, and I'm continually struck by how well regular open source development processes effectively take care of a lot of the testing needs intrinsically.)

Thanks for posting your meeting minutes online, that's been very useful for catching up on your status. I notice a couple of the recent ones are broken links though...

You mention that the jabber.org server is crowded and slow. You could try using the gristle.org server that we use for Inkscape's Jabber chat.

I think what you've posted at the inkboard.sf.org site is quite adequate. Looks like you have an effective documentation approach (much better than Inkscape's!) You could place a link in the Inkscape Wiki to your site, but otherwise unless you really want to use Inkscape's wiki, no need.

I would strongly encourage you to post a File Release on your SourceForge project. Focusing on making frequent, regular releases will get you into a good habit and will make it easier for the rest of the community to provide feedback and contributions to you. Post both source code and compiled packages, if possible. Don't worry if the first release isn't complete or if it's buggy; get the first release out, and keep putting out incrementally better releases.

Keep up the work, this is looking to be an extremely cool project. I think this'll be an excellent addition to the open source community, too.

Bryce

On Thu, 3 Feb 2005, Montgomery, Steven S wrote:

No, we don't have our code linking normally. Since it was such a brickwall for our progress, we moved the Jabber code into a file we added under dialogs(where it was being called from). Obviously this links, but we definitely would like to separate the code back out how it should be.

I've seen some recent posts about automake 1.9 causing problems for some people. Perhaps that is our issue as well?

It's not clear to me where our documents would be appropriate in the Inkscape Wiki.

However, we do have all of our documents and sourcecode available online. The documentation is at http://inkboard.sourceforge.net and our code is in the Sourceforge CVS(/cvsroot/inkboard/). The Inkboard module is the correct one(we plan to clean up the CVS repository at some point).

Steven Montgomery

---

This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel