Do we need to enhance our community? How?

Hi all, 

lately I am concerned about our community. 

I see many strong individuals that have different
philosophies about the
way this project should work and how we should develop our
code.

This normally is not a problem for other projects here on
Apache because
people just swallow their ego and trying to find a consensus
on a
project base. In the sense of what is best for the *PROJECT*
(!!!), here
it seems very different. 

Instead of reaching a consensus it seems some people just do
their own
thing and not care too much about the opinion of this
community. Latest
examples is our guideline discussion that just stopped
because we could
not get a consensus in starting it. This is quite typical
for this
project, someone rejects a proposed way, regardless that she
is alone in
this rejection, and then the whole issue does not get
touched for the
next three month.

Another phenomenon is the lenya fork that some committer are
developing
outside of the ASF. IMO that is very scary, but I see this
as
consequence of a week community that is not able to find
consensus. It
seems that we prefer to go the way of least resistance. I
would like to
have a branch for the fork here in our code base. This way
we all can
review the work and hopefully enhance usability.

IMO we *all* need to get a grip and try to solve this
problem. We cannot
waste resources in having endless discussions or having good
ideas in a
non ASF fork.

How can we solve this problem? 

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Thorsten Scherler wrote:
> Hi all, 
>
> lately I am concerned about our community. 
>
> I see many strong individuals that have different
philosophies about the
> way this project should work and how we should develop
our code.
>
> This normally is not a problem for other projects here
on Apache because
> people just swallow their ego and trying to find a
consensus on a
> project base. In the sense of what is best for the
*PROJECT* (!!!), here
> it seems very different. 
>
> Instead of reaching a consensus it seems some people
just do their own
> thing and not care too much about the opinion of this
community. Latest
> examples is our guideline discussion that just stopped
because we could
> not get a consensus in starting it. This is quite
typical for this
> project, someone rejects a proposed way, regardless
that she is alone in
> this rejection, and then the whole issue does not get
touched for the
> next three month.
>   

well, I don't think it's 3 months since then and I would
argue in my case
that I would have more time to help on the guidelines if I
wouldn't have 
to fix stuff which got broken ...

Re the guidelines in particular my point was that we start
with a clean 
sheet and use the Forrest guidelines
for inspiration so I don't see any reason why we cannot
progress there 
step by step, e.g. starting with an index/contents.
> Another phenomenon is the lenya fork that some
committer are developing
> outside of the ASF.
what forks? You might want to be explicite on this.

>  IMO that is very scary, but I see this as
> consequence of a week community that is not able to
find consensus. It
> seems that we prefer to go the way of least resistance.
I would like to
> have a branch for the fork here in our code base. This
way we all can
> review the work and hopefully enhance usability.
>
> IMO we *all* need to get a grip and try to solve this
problem. We cannot
> waste resources in having endless discussions or having
good ideas in a
> non ASF fork.
>   

again, what fork?
> How can we solve this problem? 
>   

by listening to each other and not just doing stuff with
high potential 
of breaking things without discussing it beforehand. This is
what really 
destroys a community.

Also I think one needs to be aware that a
"democracy" can get stuck and 
one shouldn't be frustrated by this, but rather one
should re-collect and then try it again from another angle.

Also I think the Lenya community should think about what
meritocracy 
actually means within this community and why
Lenya exists. If we don't find consensus on this, then we
will never be 
able to get along and move "beyond".

Michi
> salu2
>   


-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
michael.wechnerwyona.com                        michiapache.org
+41 44 272 91 61


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

El lun, 29-05-2006 a las 15:12 +0200, Michael Wechner
escribió:
> Thorsten Scherler wrote:
> > Hi all, 
> >
> > lately I am concerned about our community. 
> >
> > I see many strong individuals that have different
philosophies about the
> > way this project should work and how we should
develop our code.
> >
> > This normally is not a problem for other projects
here on Apache because
> > people just swallow their ego and trying to find a
consensus on a
> > project base. In the sense of what is best for the
*PROJECT* (!!!), here
> > it seems very different. 
> >
> > Instead of reaching a consensus it seems some
people just do their own
> > thing and not care too much about the opinion of
this community. Latest
> > examples is our guideline discussion that just
stopped because we could
> > not get a consensus in starting it. This is quite
typical for this
> > project, someone rejects a proposed way,
regardless that she is alone in
> > this rejection, and then the whole issue does not
get touched for the
> > next three month.
> >   
> 
> well, I don't think it's 3 months since then 

No, that is a general observation and with the guidelines
this will
hopefully not happen.

> and I would argue in my case
> that I would have more time to help on the guidelines
if I wouldn't have 
> to fix stuff which got broken ...

Everybody is involved in her real life and other projects.
Nobody can be
constantly 100% involved in this community and this is
perfectly
alright.

The guidelines is a general example for a pattern in
discussion I see. 

> 
> Re the guidelines in particular my point was that we
start with a clean 
> sheet and use the Forrest guidelines
> for inspiration so I don't see any reason why we
cannot progress there 
> step by step, e.g. starting with an index/contents.

Here we go again. 

...and that is exactly the point.

I and other do not see any reason why to do it step by step.
Like Gregor
said because we can is not a reason.  I still do not see any
reason why
we have to do it like *you* want. 

It would help this community if you drop your position of a
blank paper
since you are the *only* one that supports it where other
started the
real discussion about guidelines. 

> > Another phenomenon is the lenya fork that some
committer are developing
> > outside of the ASF.
> what forks? You might want to be explicite on this.

Please read our dev and user mails carefully. There you find
solprovider
talking about such efforts. 

> 
> >  IMO that is very scary, but I see this as
> > consequence of a week community that is not able
to find consensus. It
> > seems that we prefer to go the way of least
resistance. I would like to
> > have a branch for the fork here in our code base.
This way we all can
> > review the work and hopefully enhance usability.
> >
> > IMO we *all* need to get a grip and try to solve
this problem. We cannot
> > waste resources in having endless discussions or
having good ideas in a
> > non ASF fork.
> >   
> 
> again, what fork?

see above

> > How can we solve this problem? 
> >   
> 
> by listening to each other and not just doing stuff
with high potential 
> of breaking things without discussing it beforehand.
This is what really 
> destroys a community.

Many problems that currently occurred (like the broken
trunk) can be
prevented with guidelines (stable trunk policy, when changes
may violate
this policy then the work needs to be done in a branch and
then merged
back). See the guidelines thread about a discussion on it. 

Blocking guidelines by forcing other to do it in a
particular way is
destroying a community. A broken trunk is not nice but it
can be fixed
by a good community. Further we explicitly state on
http://lenya.a
pache.org/1_4/index.html
"Warning
Apache Lenya 1.4 is still under heavy development and should
not be used
for production yet." 

If people ignore this warning then they doing it on their
own risk, or?

Now a "stable trunk policy" in combination with
a branch policy in our
guidelines may have prevented this, don't you think?


> 
> Also I think one needs to be aware that a
"democracy" can get stuck and 
> one shouldn't be frustrated by this, but rather one
> should re-collect and then try it again from another
angle.
> 

...but not if *one* person is vetoing all the time. That is
burning the
one that is proposing because she needs to re-do the whole
process again
and again from different angles. 

> Also I think the Lenya community should think about
what meritocracy 
> actually means within this community 

This is part of the guidelines, therefore we first need to
have/discuss
a guideline for it.

> and why
> Lenya exists. 

I do not understand? 

I thought that is http://lenya.apa
che.org/charter.html for.

> If we don't find consensus on this, then we will never
be 
> able to get along and move "beyond".

...because you say so?

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Thorsten Scherler wrote:

>> Re the guidelines in particular my point was that
we start with a clean 
>> sheet and use the Forrest guidelines
>> for inspiration so I don't see any reason why we
cannot progress there 
>> step by step, e.g. starting with an index/contents.
> 
> Here we go again. 
> 
> ...and that is exactly the point.
> 
> I and other do not see any reason why to do it step by
step. Like Gregor
> said because we can is not a reason.  I still do not
see any reason why
> we have to do it like *you* want. 
> 
> It would help this community if you drop your position
of a blank paper
> since you are the *only* one that supports it where
other started the
> real discussion about guidelines. 

+1

> Now a "stable trunk policy" in combination
with a branch policy in our
> guidelines may have prevented this, don't you think?

rapid development causes instability, pretty much by
definition. the 
problem here is not that trunk is unstable at times but that
the 1.4 
branch should have happened a long time ago, but did not.
which lured / 
forced people into relying on trunk for their business,
which is wrong.

> ...but not if *one* person is vetoing all the time.
That is burning the
> one that is proposing because she needs to re-do the
whole process again
> and again from different angles. 

+1

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

I only mentioned my fork to support my ideas about improving
trunk.  I
only started the fork because I was in a high-speed car
accident, my
brain was damaged, and I needed a project to prove my
technical skills
were fine.

You are aware of the fork because I mentioned it in the
thread about
handling extensions.  I suggested an easy algorithm, and
mentioned
that it already worked in my version.  The thread continued
without a
response to my comment.

"We cannot waste resources in having endless
discussions or having
good ideas in a
non ASF fork."

But none of my ideas are "good".  I am not part
of the development
effort because my ideas have been completely spurned.  Every
suggestion I have made about Lenya has been discarded by the
other
Committers.  Most of the issues discussed on the dev list
were fixed
or avoided in my fork because I fixed the architecture. 
Attempting to
pass that knowledge back to the 1.4 developers generated
this
complaint.

I did not start the fork because my suggestions are
disdained.  I did
not do it to hurt the project in any way.  I needed to write
code, and
could use a better version of Lenya.  I'm scratching my own
itch for a
few hours each week.  My code and ideas are unwanted in
trunk, so how
does my private work hurt the project?

I would enjoy adding a branch at ASF, but why do it?  It
would risk
splitting the effort between the current 1.4 and a simpler,
easier,
more flexible version.  The programmers enjoy working on the
complex
version.  The users who would benefit from the easier
version  could
not add value to it.  The fork is probably better as my
private
project.

solprovider

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Hi:

solproviderapache.org escribió:
> I only mentioned my fork to support my ideas about
improving trunk.  I
> only started the fork because I was in a high-speed car
accident, my
> brain was damaged, and I needed a project to prove my
technical skills
> were fine.
I didn't know that and I hope every thing is ok.
>
> You are aware of the fork because I mentioned it in the
thread about
> handling extensions.  I suggested an easy algorithm,
and mentioned
> that it already worked in my version.  The thread
continued without a
> response to my comment.
>
> "We cannot waste resources in having endless
discussions or having
> good ideas in a
> non ASF fork."
>
> But none of my ideas are "good".  I am not
part of the development
> effort because my ideas have been completely spurned. 
Every
> suggestion I have made about Lenya has been discarded
by the other
> Committers.  Most of the issues discussed on the dev
list were fixed
> or avoided in my fork because I fixed the architecture.
 Attempting to
> pass that knowledge back to the 1.4 developers
generated this
> complaint.
I've been in different Open Source communities since 1999.
In this few 
years, I learned the real power of an open source community
is in his 
diversity. The capacity to see the same problem from
different points of 
views. The ability to find different solutions, different
improvements. 
This is what make us strong. At the same time, I learned
often people 
needs time to digest new ideas. I can say, it's natural,
because our 
human nature is usually against changes. When an idea is not
welcomed at 
the first introduction, we should prefer to give people some
time to 
think about the issue and return to it later, perhaps in a
couple of 
weeks the community can provide a better input or welcome
the idea.

>
> I did not start the fork because my suggestions are
disdained.  I did
> not do it to hurt the project in any way.  I needed to
write code, and
> could use a better version of Lenya.  I'm scratching
my own itch for a
> few hours each week.  My code and ideas are unwanted in
trunk, so how
> does my private work hurt the project?
I just can say: Wow! I wondered where you had been. Reading
this mail is 
sad to me. Not because of you, solprovider, I cannot express
how much I 
apreciate your openess. It's sad because seems the whole
community 
situation is already worse than we expected. The ASF is
mostly about 
communities, the code is not the most important. At the same
time, I 
will like to point you to Rules for Revolutionaries [1].
Please take 5 
minutes and read it.
>
> I would enjoy adding a branch at ASF, but why do it? 
It would risk
> splitting the effort between the current 1.4 and a
simpler, easier,
> more flexible version.
I will like to see your version. Is there a demo?
> The programmers enjoy working on the complex
> version.  The users who would benefit from the easier
version  could
> not add value to it.
Sometimes it's not the case. 
> The fork is probably better as my private project.

Please reconsider this.

Best Regards,

Antonio Gallardo

[1] http://incubator.apache.org/learn/rules-for-revo
lutionaries.html

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

solproviderapache.org wrote:
> I only mentioned my fork to support my ideas about
improving trunk.  I
> only started the fork because I was in a high-speed car
accident, my
> brain was damaged, and I needed a project to prove my
technical skills
> were fine.
> 
> You are aware of the fork because I mentioned it in the
thread about
> handling extensions.  I suggested an easy algorithm,
and mentioned
> that it already worked in my version.  The thread
continued without a
> response to my comment.

I hope you don't feel offended by Thorsten mentioning your
fork.
I don't think it was meant as an accusation, but he rather
wanted
to substantiate the statement that the community needs a
stronger sense
of collaboration and joined efforts. Sorry, of course
Thorsten can
speak for himself 


> "We cannot waste resources in having endless
discussions or having
> good ideas in a non ASF fork."

Maybe sometimes ideas need time and space to emerge and
evolve outside
the main project. For instance, I have committed some things
to the
trunk and reverted them later on - with the current rather
sensible
state of the trunk I'd rather use a branch or temporary
fork for that
and commit the concepts that have proved useful. BTW, I hope
that
this state of affairs re. the meaning of the trunk will
change soon.
IMO the trunk should be the place where ideas can be
implemented and
tested, reviewed by the community, and reverted if they are
not useful.


> But none of my ideas are "good".  I am not
part of the development
> effort because my ideas have been completely spurned. 
Every
> suggestion I have made about Lenya has been discarded
by the other
> Committers.

 From my point of view, that's not generally because we
dislike the
ideas, but because they are too far away from the current
state
of Lenya. I find many of your proposals regarding the
repository API
(e.g., the naming of classes etc.) very interesting and
useful.
And AFAIK your improvements of the search engine are
appreciated and
used by the community.


> Most of the issues discussed on the dev list were fixed
> or avoided in my fork because I fixed the architecture.
 Attempting to
> pass that knowledge back to the 1.4 developers
generated this
> complaint.
> 
> I did not start the fork because my suggestions are
disdained.  I did
> not do it to hurt the project in any way.  I needed to
write code, and
> could use a better version of Lenya.  I'm scratching
my own itch for a
> few hours each week.  My code and ideas are unwanted in
trunk, so how
> does my private work hurt the project?
> 
> I would enjoy adding a branch at ASF, but why do it? 
It would risk
> splitting the effort between the current 1.4 and a
simpler, easier,
> more flexible version.  The programmers enjoy working
on the complex
> version.  The users who would benefit from the easier
version  could
> not add value to it.  The fork is probably better as my
private
> project.

Thanks for explaining this!

-- Andreas


-- 
Andreas Hartmann
Wyona Inc.  -   Open Source Content Management   -   Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
andreas.hartmannwyona.com                     andreasapache.org


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Thorsten Scherler wrote:
>
> Here we go again. 
>
> ...and that is exactly the point.
>
> I and other do not see any reason why to do it step by
step. Like Gregor
> said because we can is not a reason.  I still do not
see any reason why
> we have to do it like *you* want. 
>   

you don't have to do things as I want. If you are able to
gather a 
majority then go ahead.
I will certainly respect that, but I will keep stating my
opinion
> It would help this community if you drop your position
of a blank paper
> since you are the *only* one that supports it where
other started the
> real discussion about guidelines. 
>   

well, this is my opinion and I have argued why I think it's
the right 
thing how to handle it
and I do not see any reason why I should change my opinion
on this. But see above.

>   
>>> Another phenomenon is the lenya fork that some
committer are developing
>>> outside of the ASF.
>>>       
>> what forks? You might want to be explicite on this.
>>     
>
> Please read our dev and user mails carefully. There you
find solprovider
> talking about such efforts. 
>   

ok, so are refering to solprovider. Why don't you ask him
directly? Then 
he might
be able to explain himself, otherwise I am afraid he will be
blamed for 
something which
doesn't apply at least not from his point of view.
>   
>>>  IMO that is very scary, but I see this as
>>> consequence of a week community that is not
able to find consensus. It
>>> seems that we prefer to go the way of least
resistance. I would like to
>>> have a branch for the fork here in our code
base. This way we all can
>>> review the work and hopefully enhance
usability.
>>>
>>> IMO we *all* need to get a grip and try to
solve this problem. We cannot
>>> waste resources in having endless discussions
or having good ideas in a
>>> non ASF fork.
>>>   
>>>       
>> again, what fork?
>>     
>
> see above
>   

as said, go and ask him (or anyone else) and it will
hopefully get 
clearer than just implying things
which nobody can be sure of.
>   
>>> How can we solve this problem? 
>>>   
>>>       
>> by listening to each other and not just doing stuff
with high potential 
>> of breaking things without discussing it
beforehand. This is what really 
>> destroys a community.
>>     
>
> Many problems that currently occurred (like the broken
trunk) can be
> prevented with guidelines (stable trunk policy, when
changes may violate
> this policy then the work needs to be done in a branch
and then merged
> back). See the guidelines thread about a discussion on
it. 
>   

see my suggestions I have made how to prevent breaking the
trunk
> Blocking guidelines by forcing other to do it in a
particular way is
> destroying a community.

I am not blocking. I am stating my opinion. As said you can
resolve that 
by gathering a majority.
>  A broken trunk is not nice but it can be fixed
> by a good community. Further we explicitly state on
> http://lenya.a
pache.org/1_4/index.html
> "Warning
> Apache Lenya 1.4 is still under heavy development and
should not be used
> for production yet." 
>   

just because it says "free speech" on a paper
doesn't mean one is able 
to speak freely.

You might have read the emails from various users why they
already use 
Lenya 1.4-dev in production ...
> If people ignore this warning then they doing it on
their own risk, or?
>   

generally yes, but it's our responsibility to deal with
that as good as 
we can.
I'd rather not got into "parenting" 
> Now a "stable trunk policy" in combination
with a branch policy in our
> guidelines may have prevented this, don't you think?
>   

yes, guidelines would certainly help on this, but it depends
of course what
the guidelines are saying 
>
>   
>> Also I think one needs to be aware that a
"democracy" can get stuck and 
>> one shouldn't be frustrated by this, but rather
one
>> should re-collect and then try it again from
another angle.
>>
>>     
>
> ...but not if *one* person is vetoing all the time.

I am not vetoing. I neither have the right to nor I want to.
But I will keep stating my opinion.
>  That is burning the
> one that is proposing because she needs to re-do the
whole process again
> and again from different angles. 
>   

nobody said democracy is an easy thing (and the right thing
in every 
situation)
>   
>> Also I think the Lenya community should think about
what meritocracy 
>> actually means within this community 
>>     
>
> This is part of the guidelines, therefore we first need
to have/discuss
> a guideline for it.
>   

yes, but at the same time we have a "daily
business" and have to deal 
with it resp. are able
to extract experience from this for the guidelines. Just
remind 
yourself, that guidelines are being
created in general because things do not work that properly 
community-wise 

I am all pro to create guidelines, but I still think we need
to start 
with a clean paper. But it's for the majority to
decide how to handle the guidelines creation. But as an
example just 
think about a country where christians are the majority
and muslims a minority. So I would assume that the
christians would like 
to start with the bible instead a clean paper.
Do you think that is fair?
>   
>> and why
>> Lenya exists. 
>>     
>
> I do not understand? 
>
> I thought that is http://lenya.apa
che.org/charter.html for.
>   

I think this charter should be rewritten 

I think the top priority is that Lenya exists because people
want a CMS 
(framework) which they can actually use
within the daily situation (there are some criteria attached
with that 
sentence of course)
>> If we don't find consensus on this, then we will
never be 
>> able to get along and move "beyond".
>>     
>
> ...because you say so?
>   

no, because I think it will actually solve problems in the
long-run.
One also needs to be aware of course that consensus it not
the same as 
majority.
And the question there is how does meritocracy fit it ...

Michi
> salu2
>   


-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
michael.wechnerwyona.com                        michiapache.org
+41 44 272 91 61


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Gregor J. Rothfuss wrote:
>> Now a "stable trunk policy" in
combination with a branch policy in our
>> guidelines may have prevented this, don't you
think?
>
> rapid development causes instability, pretty much by
definition. 

not at all
> the problem here is not that trunk is unstable at times
but that the 
> 1.4 branch should have happened a long time ago, but
did not. which 
> lured / forced people into relying on trunk for their
business, which 
> is wrong.

that's reality and we need to deal with it. It doesn't
help that much to 
say it's wrong that so many women are being raped within
wars, the 
question is how to deal with it now, try to improve the
situation and 
prevent it in the future.

I made a couple of suggestions how we can deal with the
current 
situation and I am confident that we will manage just fine,
but it's 
important that we all make ourselves clear what we actually
want and 
then we can go ahead.

Michi

-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
michael.wechnerwyona.com                        michiapache.org
+41 44 272 91 61


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Michael Wechner wrote:

[...]

>> How can we solve this problem?   
> 
> by listening to each other and not just doing stuff
with high potential 
> of breaking things without discussing it beforehand.
This is what really 
> destroys a community.

IMO with a CTR policy every committer should decide when a
change should
be discussed. Sometimes the decision can be wrong - for
instance, I have
recognized that I should have discussed some of my recent
changes before-
hand. But then a discussion can follow, and changes can be
reverted.
I think it is important how the community handles such a
situation.

"Breaking things" is not always a bad thing,
sometimes a change just shows
where problems exist (e.g., a change to the repository layer
might show
where the layer was bypassed). Even the perception if
something is
"broken" can depend on the point of view. E.g.,
IMO things are really
broken if principles like SoC or IoC are violated, or
antipatterns occur.
Functional bugs can be fixed, I don't consider them real
problems
(at least in an unstable branch).

I share Thorsten's concerns about the community.

Some ideas how to improve it from my point of view:

- Stronger participation in discussions, reacting to
proposals.
   Even a "+-0" or "Interesting, but I
have no idea" is great.

   People should feel encouraged to express their ideas on
the list.
   I have to admit that I'm rather discouraged, which
unfortunately
   resulted in unannounced commits. Correct me if I'm
wrong, but in
   the case of others it might result in holding back ideas.

- Focusing on solutions (example: the guidelines thread).
   IMO we should start with existing guidelines.
   Just my $0.02 - I'm the type of person who is motivated
by progress.


-- Andreas


-- 
Andreas Hartmann
Wyona Inc.  -   Open Source Content Management   -   Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
andreas.hartmannwyona.com                     andreasapache.org


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Michael Wechner wrote:

[...]

>>> and why
>>> Lenya exists.     
>>
>> I do not understand?
>> I thought that is http://lenya.apa
che.org/charter.html for.
>>   
> 
> I think this charter should be rewritten 
> 
> I think the top priority is that Lenya exists because
people want a CMS 
> (framework) which they can actually use
> within the daily situation (there are some criteria
attached with that 
> sentence of course)

IMO it's very important that we agree on these criteria.
I'm still orienting to the roadmap diagram. Maybe it should
be reworked?

-- Andreas

-- 
Andreas Hartmann
Wyona Inc.  -   Open Source Content Management   -   Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
andreas.hartmannwyona.com                     andreasapache.org


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

solproviderapache.org wrote:
> I only mentioned my fork to support my ideas about
improving trunk.

I am glad you did
> I
> only started the fork because I was in a high-speed car
accident, my
> brain was damaged, and I needed a project to prove my
technical skills
> were fine.

hope it proved that you are alright again
>
> You are aware of the fork because I mentioned it in the
thread about
> handling extensions.  I suggested an easy algorithm,
and mentioned
> that it already worked in my version.  The thread
continued without a
> response to my comment.

well, that doesn't mean nevessarily people aren't
interested. For 
instance in my case
I am just too occupied with my own stuff and I am struggling
to properly 
respond to all
suggestions.
>
> "We cannot waste resources in having endless
discussions or having
> good ideas in a
> non ASF fork."
>
> But none of my ideas are "good".  I am not
part of the development
> effort because my ideas have been completely spurned. 
Every
> suggestion I have made about Lenya has been discarded
by the other
> Committers.  Most of the issues discussed on the dev
list were fixed
> or avoided in my fork because I fixed the architecture.
 Attempting to
> pass that knowledge back to the 1.4 developers
generated this
> complaint.
>
> I did not start the fork because my suggestions are
disdained.  I did
> not do it to hurt the project in any way.  I needed to
write code, and
> could use a better version of Lenya.  I'm scratching
my own itch for a
> few hours each week.  My code and ideas are unwanted in
trunk, so how
> does my private work hurt the project?

it doesn't hurt at all. It's good and I hope that Lenya
will be able to 
use stuff from it
>
> I would enjoy adding a branch at ASF, but why do it? 
It would risk
> splitting the effort between the current 1.4 and a
simpler, easier,
> more flexible version.

agreed
> The programmers enjoy working on the complex
> version.  The users who would benefit from the easier
version  could
> not add value to it.  The fork is probably better as my
private
> project.

 I am not sure if I understand you on this. Can you explain
a bit.

For instance I do a lot
of things within svn.wyona.org/repos/public and I think it
would be bad 
if I would upload everything
into the Lenya SVN just because I am a committer and have
the 
possibility to do so. And I think
every committer should behave like this so it seems to me
that you are 
doing the right way.

Michi
>
> solprovider
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
> For additional commands, e-mail: dev-helplenya.apache.org
>
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
michael.wechnerwyona.com                        michiapache.org
+41 44 272 91 61


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

Michael Wechner wrote:

[...]

> For instance I do a lot
> of things within svn.wyona.org/repos/public and I think
it would be bad 
> if I would upload everything
> into the Lenya SVN just because I am a committer and
have the 
> possibility to do so. And I think
> every committer should behave like this so it seems to
me that you are 
> doing the right way.

IMO there's a difference if you use your personal
repository to
try out things and test ideas, or if you keep things private
because
you're afraid that the community might reject them.

If one has the feeling that some code is useful, I think she
or
he should commit it. If others think that it is not correct
or
appropriate for whatever reasons, they should express this
on
the mailing list. In general, this should result in
improving the
committed code rather than rejecting it, or in implementing
the
idea in another way.

-- Andreas


> 
> Michi
>>
>> solprovider
>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
>> For additional commands, e-mail: dev-helplenya.apache.org
>>
>>
> 
> 


-- 
Andreas Hartmann
Wyona Inc.  -   Open Source Content Management   -   Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
andreas.hartmannwyona.com                     andreasapache.org


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

El mar, 30-05-2006 a las 02:13 -0400, solproviderapache.org escribió:
> I only mentioned my fork to support my ideas about
improving trunk.  I
> only started the fork because I was in a high-speed car
accident, my
> brain was damaged, and I needed a project to prove my
technical skills
> were fine.

That is perfectly alright, but having this work in the ASF
rep would
help to review your ideas and we benefit on a project base.

> 
> You are aware of the fork because I mentioned it in the
thread about
> handling extensions.  

Well, you mentioned it a couple of times in different
threads, sometimes
you refer to this work as lenya-1.3.

> I suggested an easy algorithm, and mentioned
> that it already worked in my version.  The thread
continued without a
> response to my comment.

That is the reason I picked it up in this thread.

> 
> "We cannot waste resources in having endless
discussions or having
> good ideas in a
> non ASF fork."
> 
> But none of my ideas are "good".  

We cannot really evaluate them. 

> I am not part of the development
> effort because my ideas have been completely spurned. 
Every
> suggestion I have made about Lenya has been discarded
by the other
> Committers.  Most of the issues discussed on the dev
list were fixed
> or avoided in my fork because I fixed the architecture.
 Attempting to
> pass that knowledge back to the 1.4 developers
generated this
> complaint.

This is a phenomenon that we need to resolve as community
that's why I
started this thread. 

It seems to me that one solution is to create a branch and
check in your
code. This way we have a pool of ideas and architecture
enhancement that
we can use. 

Regarding the complains of others, we need to find a more
productive way
to discuss this points in this community. Having code
examples is
helping me personally a lot more then dry discussions.

> 
> I did not start the fork because my suggestions are
disdained.  I did
> not do it to hurt the project in any way.  I needed to
write code, and
> could use a better version of Lenya.  I'm scratching
my own itch for a
> few hours each week.  My code and ideas are unwanted in
trunk, so how
> does my private work hurt the project?

Yes and no. IMO it hurts the project not having your code.
We are
loosing valuable ideas. 

Let me state crystal clear (in the name of the Lenya PMC)
that your code
is wanted. Let us create a branch and see how we can reuse
your work in
the trunk.
 
> 
> I would enjoy adding a branch at ASF, but why do it? 
It would risk
> splitting the effort between the current 1.4 and a
simpler, easier,
> more flexible version.  

Actually I do not see this risk. Since now you are the only
one working
on the version but maybe people will join you and we can
enhance the
trunk as well.

> The programmers enjoy working on the complex
> version.  

I consider myself as programmer and believe me I do *not*
enjoy working
on complex things and I would love to see a simpler version.

> The users who would benefit from the easier version 
could
> not add value to it.  The fork is probably better as my
private
> project.

It is your decission but like I stated I see it as lost for
this
project, which makes me sad. 

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org