[discuss] Welcome to LinuxProgramming.com!

[Kevin Cullis <kevincu orci com>]

Steffen,

You're moving in the right direction.  Below are my comments.  You did a
great work on your thesis and I commend you.

Steffen Evers wrote:
> 
> Hello,
> 
> Issuezilla is a great idea and basing it on Bugzilla is even better. There are
> several things I like to discuss about the collaboration model it is based on.
> 
> About my background: I am a computer scientist and working at the Technical
> University of Berlin right now. The subject of my diploma thesis was
> "Development Environments For Open Source Software" (available online at:
> http://user.cs.tu-berlin.de/~tron/opensource ). It is the result of my one year
> of research in the field of open source software (OSS). The topic turned out to
> be so complex that I was forced to spend the entire time on building a solid
> base for further work and identifying fundamental structures in OSS development.

This is most crucial to improving the Linux development model to achieve
world domination ;-).  While I'm not from the Cathedral model, the
bazaar method needs to progress toward a sort of "franchise" model, one
in which communication between the various entities: developers,
documentation, UI, distributions, etc. is shared quite readily and
fluidly.  Right now, I'm communicating with about six mailing lists
regarding Linux development and duplication of effort is rampant, which
ends up slowing Linux development. Notice I did not say "controlling"
Linux development, I said "communicating." I focus on ways to improve
this process, not to control it, by going slower we can go faster.

> 
> There are many things about development environments for OSS I would like to
> discuss, but the one that might be most interesting for you are the categories
> of issues as you have them in Issuezilla:
> 
> I have divided issues in several categories in my thesis, too, but with a
> different result (See http://user.cs.tu-berlin.de/~tron/opensource/node17.html
> for more):
> 
> 1. Bug (your DEFECT): Someone discovered a strange behavior of a software
> component.

I'm glad you have DEFECT, because that's what all bugs are: DEFECTS!

> 
> 2. Improvement (your ENHANCEMENT): A user or developer has a good idea to
> improve a component in some respect at processing a certain task.
> 
> 3. New Feature (your FEATURE): A suggestion to integrate some new functionality.
> 
> 4. Question (no equivalent): A person requires some information about a certain
> matter.
> 
> 5. Comment (no equivalent): Someone wants to share certain information with
> another involved person. (e.g. an important project started)
> 
> * Why Question and Comment?
> This is a step towards creating an issue based communication platform. People
> are often only interested in certain issues and not the entire development work.
> Therefore I was thinking about an (additional) communication system. Mailing
> lists seem to be unsatisfying for this purpose.

Absolutely! Mailing lists should be for discussing issues, but in the
end, summaries/conclusions/etc., need to go into a document of some sort
for people to refer to as the "bible " of the development process.

> 
> * Questions:
> It is a basic principle of OSS to involve at least highly skilled users in the
> development process and make them co-developers. Questions are issues which
> have not been clearly identified as Bug, Improvement, Feature or simply missing
> knowledge of the reporter. Typically, users or new developers have a lot to ask
> or question, but are not sure about the value for the project because of missing
> information. Nevertheless, their ideas might help a lot to see the project from
> a new perspective and identify shortages. The basic idea is to support a
> collaborative brainstorming at an early stage.
> 
> * Comments:
> A comment should not belong to one of the other categories. Their introduction
> is based on the observation that there are often information which do not really
> need to be processed, but might be valuable hints for someone. Thinking of a
> mailing list this is something you would not post because it is to specific and
> not important enough without further work for the entire list. An issue based
> communication makes specific information more attractive and again supports
> effective information exchange at an early stage.
> 
> The current version of Issuezilla supports two other issues: TASK and PATCH
> 
> * TASK:
> Do TASKs really fit in the list above? In my point of view, TASKs are
> (sub-) issues. The introduction of an entire issue hierarchy would be much
> cleaner. So, each issue could have any of the given (sub-) issues.
> 
> * PATCH:
> Again, a PATCH is a sub-issue or maybe a combination of an listed issue and the
> corresponding solution. Patches are (possible) solution for an issue, like the
> answer to a question. It would be cleaner to split the issue from the solution,
> e.g. when implementing an issue hierarchy PATCH should require a parent issue
> object.
> Reasons: Firstly, a patch could be a bugfix, feature or an enhancement.
> Secondly, other developers might provide a (better) solution for the same
> problem. Thirdly, an exact definition of the fixed problem helps to identify and
> avoid conflicts with other modification.
> Problems: More effort than simply providing a patch.
> 
> I hope some people send a comment or patch on this issue. :-)
> 
> Greetings, Steffen

I'll have more comments as I have time.

Kevin

P.S. Your Software production graphic should be similar to the process
improvement model:  Plan->Do->Check->Act and the arrows should move in a
clockwise fashion to indicate moving forward.-------------------------------
Attachment: kevincu.vcf.1 (text/x-vcard)
Call MIS Department for details
-------------------------------