Re: [Arianne-devel] Life cycle

[<dv...@in...>]

Quoting Miguel Angel Blanch Lardin <mig...@ho...>:

> >Since any project begins with many steps prior to an alpha release, won't 
> >the next release after a complete re-design be alpha #1, again?
> 
> Code is not relevant really, code is the tool to implement designs that 
> work, what we are alpha testing is design and not code.
> 
> Code can be written in less than 2 weeks once design is stable.
> 
> 
> >Also, barrier to entry seems to be a bit high here. Higher than the Linux
> >kernel. There I could just pick something off the kernel janitor's todo
> >list and do it because the cause for most aspects of the project are 20
> >years old. Because the majority of the Arianne system is conceptually new
> >to most developers (there just haven't been enough MORPG to have enough
> >experienced developers), the todo lists for newbies need to be much more
> >detailed, explaining the cause behind the action.
> 
> Agree, also most people that "wanna" help usually skip to read the 
> documentation that explain the whole engine concepts.
> 

Understood, but as this project seems to be redesigned once a year or so many 
of the tasks are design issues. This generally means The objectives of the 
intermingling portions of the project need to be clearly defined. For example, 
how can you design a quest system without a reasonably complete RP system?


> >They also need to list
> >the mandatory requirements of the product of the newbie's work. For
> >example, "Create the script to help automate the creation of objects".
> >Which type of objects? Where are they stored? 'the script' implies that it
> >is started, if so, where is it now? Who is working on it? Who started it?
> >What are the prerequisites? What is the current process for creating
> >objects? Now this might be a tad overdone, but while these may seem
> >obvious to you, people new to the project haven't a clue. I'm sure the
> >list would answer these questions and a half-skilled developer can figure
> >these out.
> 
> ok, I totally agree with you that what you propose is the correct way to 
> generate bugs, but if we document bugs in such a way we lose more time 
> documenting it that actually fixing it.

I understand. I'm talking about taking an extra three-four minutes per task to 
write an appropriate summary. Just list all the requirements of the 
deliverable, if nothing else.


> Most ( ALL ) the bugs posted on SF are trivial ones, and take no more than a
> 
> few hours to be fixed correctly. That is the cause that generating correct 
> doc for them is usually not recommended, as waba posted most of them are 
> "Remind me later" ones
> 
> Again, I accept the critic and will try to improve the bug docs, but again I
> 
> have to see practical results. I can't spend two hours day adding bugs and 
> see no new help on the project. Do you understand?

Completely. Is a group-based task management system the best place to put a 
fairly personal todo list, though?


> >A newbie is probably saying "Oh god.. I'm not doing that one"
> >and moves on down the list repeating this to himself until he finds a
> >trivial task or gets to the bottom and goes to a different project
> >figuring he will come back to us when get a little more organized.
> 
> Agree, I understand that arianne is a bit big for someone that dislike 
> reading and asking, but I will try to improve organization.
> 
> I will add this as a Feature Request.
> 

Awesome!

Btw, I am quite willing to help organize and foster collaboration. If anything 
needs something done, just ask.

Regards,
Drew Vogel


-------------------------------------------------