Hello Tony!
Now that you are asking specific questions, I am not really sure what I
shall do with them. Let me just answer knowing that it is from my
perspective only.
Comments inline...
2008/8/25, Tony | Zearin <[EMAIL PROTECTED]>:
> Hello!
>
> Linus Tolke wrote:
>
> You are right Tony, of course this is the way it is and the problems we are
> facing and over the past years several people has expressed similar
> concerns.
> The main question for me is, how do we fix it? What shall I do? What
> shall we do?
> I have not yet a solution to this. We need suggestions of concrete things
> to do. Things suggested before I have either not understood or thought too
> vague to be implementable.
>
> Yep—it's definitely a tall order.
>
> But ignoring an illness even as the symptoms worsen and spread does not
> help cure it in any way. :(
>
I have a problem with this description. I think that things have improved
slightly over the past years. There is a lot more enthusiasm and creativity
now than three years ago. We have constructive discussions in issues and on
the dev mailing list and we are working as a team helping each-other. This
is great!
On the other hand, we still have a long way to go to be able to release
a high-quality product.
> Let me highlight this bit:
>
> I have not yet a solution to this. We need suggestions of concrete things
> to do. Things suggested before I have either not understood or thought too
> vague to be implementable.
>
> Agreed. But rather than jumping directly to this, I think a very important
> step is to *ask the right questions*.
>
> Asking, "What shall I do? What shall we do?" are big questions that are
> hard to answer. By breaking this big question into smaller questions—or
> asking the same big questions from a specific angle—it's easier for more
> people to participate, because it's easier to answer specific bits like
> that.
>
> To that end, let me start off with these:
>
> - What are the most painful parts of the development process?
>
> That we are incapable of discussing and communicating system architectural
issues.
>
> -
> - What tools are you currently using that are
> frustrating/painful/tedious?
>
> My old computers! With the development environment moving into Eclipse
requiring me to run both Eclipse and ArgoUML to do testing and development,
my lap-top with merely 512M memory and Windows is not good enough. I often
avoid starting Eclipse for that reason working on non-code related issues
instead.
>
> -
> - Are there any "bad habits" or recurring problems in the dev
> process?
> (This could be problems with the system or "bad habits" of people
> themselves. I'm talking about the stuff that's been around so long you
> put
> up with it because it feels like it's always been that way. But truly,
> it
> doesn't have to be!)
>
> Developers are very silent. This is especially cumbersome in three areas:
- Suggesting new developers.
- Announcing their plans and personal milestones for the benefit of
fitting a bigger release plan.
- Claiming responsibility / announcing intentions in a specific part of
the project.
>
> - What are the weak spots in our developer community?
> (I.E., do we have a very small number of people familiar with component
> X, even though X really needs work?)
>
> The weak spots are that we don't know in what part of the code we have
developers working or indeed good experience. There is a risk that this will
have the consequence that the developers are overly cautious when it comes
to doing things because they are afraid that somebody else knows better.
>
> - What are open source communities (like Inkscape) doing that we are
> not?
>
> I don't know what the big difference is. They use blueprints. They
encourage people to send in patches. They have a roadmap with the purpose
of the next 10 or so releases. They have a clearer distinction between users
and developers.
>
> - From John Daigle's e-mail (some paraphrased):
> - Is it time to start over with new requirements and architecture?
>
> This is always a tough decision to make. Of course, I don't think so. I
think the system is still fixable.
>
> -
> - If people CAN create a feature without having it implement undo,
> is that an indication that the object model is flawed?
>
>
>
> - If people CAN create a feature without having it implement undo, is
> that an indication that the object model is flawed?
>
> Yes, probably. Go ahead and fix it!
- Could it be that solving that problem in a way that insures new
features implement Undo means changing how new features are added?
Yes, probably. I don't think that we should refrain from doing improvements
because it would affect how new features are added. On the other hand, we
should try to make it easier to add new features but these objectives are
not really in conflict.
- What are the missing/incomplete features of ArgoUML that could be
obtained from other Open Source projects?
There is a plan, to replace the manually coded AWT-based framework for the
framework and workbench with Eclipse RCP. This will releave us of all
framework and workbench-issues so that we can focus entirely on the
UML-stuff. I still think that we have some work to be done here but I hope
that we soon can start releasing Eclipse RCP-versions of ArgoUML regularly.
- And last, but not least: *What makes development fun?*
Creating things. Learning things. Showing things you have done to others.
The feeling that others can benefit from your work and learn from your
ideas.
/Linus
