Mailinglist Archive: opensuse-project (783 mails)

< Previous Next >
Re: [opensuse-project] More Support for the openSUSE Project
  • From: alpha096@xxxxxxxxxxxxxxxxxxxxxx
  • Date: Tue, 18 Aug 2009 06:51:24 +1000
  • Message-id: <4A89C2CC.9010303@xxxxxxxxxxxxxxxxxxxxxx>
In any has worked out the outrageous interpersonal issues in this 90's
Model has cause in the work-face - let that by done in private

alpha096@xxxxxxxxxxxxxxxxxxxxxx wrote:
(Warning! The Post Below is long and contains High levels of English
that cannot be simplified in construction nor theme)

Roland, I have Posted at this level to hopefully start a dialogue about
development models.
Others who have been in a software development role for a long time,
will understand why I have introduced the topic now.

I will refer to the word 'me', on behalf of those who have seen various
development models over the years.

I hope the discussion will be fruitful.

Is there a division of work between the Systems Analyst and the
Programer, or are you still using the 1990's Model, to combine the roles
into one person?
This may be a strange question to some, but it goes to the heart of
production of software that is tecknocratically based in design and
function.

I can answer my own question very quickly from thousands of miles away,
as it is clear you are still maintaining the Systems Analyst and
Programer being the one person, and have the dual responsibility.

This certainly does reduce numbers of staff, but it was clear in the
90's, that is was fundamentally flawed.

It would be a bit like combining the matre de of a restaurant with the
head chef.
The food would be technically very good, but there would be little on
the menu and the service to the customers would fail badly.

There is an innate difference between usability and functionality; and
tecknobility that always wins.

It is not possible to separate the code cutter from the designer,
although around the world we tried very hard to do this in the 90's.
We all saw software that could do many things, but no one could or would
use it, as the interface was not designed around the user.
Here I am excluding myself as a user, and everyone who reads this must
do the same. We are so boged down with the perspective that, we cannot
make a change to the software design because of a technical issue. The
user just wants software to work and follow simple logic, but the code
cutter puts the breaks on an idea or concept in the first place, because
of a technical issue.

Lets have a look at a simple example. We all know that once we commit
any service driven application in Yast, we cannot stop the process by
clicking on the Cancel button.

Have a quick look at the following bugs and the tecknocratic response to
a common sense problem we have all had.
I have excluded my own bug report that precipitated the following bugs
and dialogue.

https://bugzilla.novell.com/show_bug.cgi?id=442173
https://bugzilla.novell.com/show_bug.cgi?id=489077

The issue is simple, the code cutter says WONTFIX, because its
technically 'impossible' or 'too hard' yet the consent
is fundamentally logical to the extreme.

I the code-cutter, WONTFIX, something that a user find simple logic in.

How do we explain to a user they cannot use the Cancel Button, because
it wont work and stop a Yast Process that hangs or misbehaves.

No user is interested in tecknobabel, the button says cancel, and they
want to cancel a misbehaving or hung process in
Yast.

The chef is dictating what the customer can eat at the restaurant.

The whole usability of the project is driven by the programmer, not the
analyst.

The software is created and changed because of technical reasons, not
functional user requirement or simple common sense logic.

The role of the Analyst/Programer always opts for the technical change
or solution.

The users logic has nothing to do with the software's design.

The user hates the software because it does not make sense to them, and
they don't buy it or want to use it.

The CEO's, Private Secretary cannot or hates using the software, and
his/her work is delayed resulting in
the CEO dismissing its possible deployment until such time as it will.

Separate the Business Analyst from the Programer and you will create
world class software, that people love and want to use and
dump the 1990's Model of combining the roles into one indivisible position.

Scott

Roland Haidl wrote:

Hi,

this is my first public message to openSUSE project, and that means first
I'd like to introduce myself: My name is Roland Haidl aka rhaidl, and I
started to work in SUSE nearly ten years ago. In that time I managed the
SUSE documentation, usability, design etc. After Novell having bought
SUSE I took over several other management task.

Now, while Novell/OPS engineering adopted to a new strategy regarding
openSUSE, we decided that the people, who Novell dedicated
to work in the openSUSE project, come under my responsibility.

For me that is awesome and something new - as it is in general. Why, since
we already had Novell people working for openSUSE in the past? Well, the
new thing that with this step Novell decided to intensify its openSUSE
sponsorship.
Now we have a group of people that is exclusively dedicated to the
openSUSE project.

It is not longer the "when time is left, please work in the openSUSE
project" thing we often had before, we now have the singular situation to
have a team of more than 10 experts in Novell to only work on openSUSE
community topics. This is the Novell "openSUSE Team", and it is there to
be a part of the community and make it easier for people to join in, enjoy
and contribute.

We (speaking as part of the Novell management) learned to trust the
community, and, as a result of this, want to support the project even
more. For proof let's see how the team will work.

Of course the team also has reponsibilities, that is basically the openSUSE
distribution and the healthy growth of the project.
Both challenges will and can only be done in a strong community with YOU
and I hope you appreciate the existance of the new team as much as I do.

The people working in the team are all well known since they already worked
a
lot in the community. I leave it up to the team to introduce itself. As
the lead of the team we nominated Klaas Freitag, who is an experienced
manager on the one hand and a community guy on the other. Henne
Vogelsang takes over the role as project manager openSUSE, and Stephan
Kulow will continue to be the release manager for the next openSUSE
distribution.


Best,
Roland


< Previous Next >
Follow Ups
References