Re: [Anarchdb-devel] Re: database layout questions?

[Karl George Schaefer]

Removed extraneous text for this reply (for clarity).  There is some good 
development talk in the previous messages, though.

> > Most of us are coming to the code for the first time and will need to
> > become accustomed to it.  We also want to hit a release date of less
> > than a week after NoR.  We want to keep our users happy and still meet
> > the needs of the new set.
>
> I was not aware of the goal of one week between NoR release and new ardb
> release otherwise i fully agree with you. We shoud make our users happy,
> then make ourselves happy with the codebase
Well, no one's actually place a date on us.  But, we've all sort of nodded 
that we need to have the new version out quickly afterwards.  In the past, 
that was about a week after, so we should try to keep up the pace.

> > After we hack together the first release, we should have ~9 months until
> > the next set, so that should give us some time to work out a development
> > plan.
>
> if i have to put a plan here i would do this in several steps:
> * include NoR in anarchdb codebase
> * i would then put a maintenance release that close all know issues
> and the new ones produced from NoR release. This would allow us all to
> accustom to the codebase and enhance our team work. By the same time
> we will set up a developpemnt plan.
> * last step: codebase refactoring.
I consider refactoring a great way for a developer to learn about his code 
base.  I would push it higher on the spectrum, simply because it gives the 
newer developers a greater sense of code ownership and a deeper 
understanding of how the code actually works.  We have very few known 
issues and it might be best to wrap them into refactoring.  Also, as I've 
looked at all of the known issues, some will be difficult to reproduce.  We 
need to get a Mac developer to check out some of them.  If we can't 
replicate the problem, we'll need to wait until it's reported again in a 
better fashion.

> > Here are some ideas that I have about a development plan:
> > 1.  Create scripts and readmes that will allow the building of ardb to be
> > easier on Windows platforms.  This is mostly completed (I'm guessing) for
> > linux.  Ease of building will allow less strong developers to aid the
> > project more easily.
>
> Agree, the app is deadly missing developpers docs. we should consider
> including doxygen to our building env to generate doc.
Never used it.  But, my chief language is Java, so sure whatever everyone's 
comfortable with.  Do you have a link to information about how to use 
Doxygen?

> > 2.  A UI group focused on good UI design that encompasses a heuristic
> > methodology about user interaction will give ARDB a higher level of
> > polish. This group doesn't need a lot of programmers.  This group needs
> > to have people that can sketch new UI designs and determine where the UI
> > currently fails the user.  There currently isn't a lot here that we need
> > to concern ourselves with, the tool is pretty straight forward.  The
> > inventory section will need some work and will probably be the focus of
> > most of these efforts.
>
> Agree. The best way should be to do it user-driven
But, we should endeavor to give the users a good product to begin with.  I 
have a list of UI heuristics that I use when developing an application. 
I'll post them later.

> >  We
> > also want to look into ways the code can be self-expanding (handling new
> > disciplines and clans without adding lines to the code).
>
> > We need database
> > designers here that can plan a reproducible work-flow that transforms the
> > WW files into our needs.
>
> agree, we should also take care of françois deck morphing issues.
What's this?

> > On the code side, we need to update to the latest
> > libraries, tighten up the code (it may be tight already, I haven't really
> > delved into it too deeply),
>
> Yes, i did notice that the codebase does not include any automatic
> unit tests. That is something i'm willing to promote.
Sure.  I used to do QA work and hated it.  So, if you're willing...

> > 5.  Request for features from users.
> >
> > There are probably other focus areas and perhaps 2 and 3 should be
> > swapped in order (and most of 4's tasks will be short and can be folded
> > in during downtime on other parts).  Anyone else have any ideas about
> > this?
> >
> > We really need to worry about this stuff *after* we get an ARDB that will
> > handle NoR.  Is everyone agreed on that?
>
> I do agree. We won't do much before releasing NoR in anarchDB.
>
> None the less i think we need to evaluate our task force to see what
> is acheavable in short and long terms
So, we have a lot of developers here.  Who can do what?  Who has time?

Karl