[CP2K:508] Re: cp2k release goals

[luca]

Hi Axel,Teo

I agree and I can be just one newbie :-)
Rules and "filter-tutor for newbie" are needed also for documents.
I think small tutorial, simple case studies,dummy examples etc...
....Not program code or developer strategy  (obvious).
The first rule could be:
Newbie can't do any rule!
:-)

Ciao
  Luca

> 
> On Jan 5, 11:11 am, Teodoro Laino <teodor... at gmail.com> wrote:
> > Ciao Luca,
> >
> > On 5 Jan 2008, at 16:03, luca wrote:
> >
> > > Most persons with not equivalent CV can use famous (some not free
> > > and not good ) programs because there are
> > > a lot of documentations, user guides, howto, and case studies.
> > > In contrast there are some very good and free program that are
> > > unknow/unused to the community
> > > and they seem do not have a lot of documentation. Is there a
> > > relationship?
> 
> yes. first off. many commercial software packages have been around
> for a looooong time and thus _more_ experience exists and is
> accessable.
> many open source projects have started much later, and people who have
> less experience tend to stick to what they know.
> secondly, commercial packages can pay people to do "unpleasant" jobs
> due to their revenues (although you have to charge ridicolously high
> amounts of money to really make some money off computational
> software).
> 
> it is also that people tend to forget the "contract" of open source
> software: everybody contributes, therefore everybody benefits.
> 
> unfortunately, over the last decade it seems as if fewer and fewer
> people are willing to invest any effort beyond of what they need
> for themselves and their own project. this goes up to the point of
> simply not reporting bugs and using (bad) workarounds instead of
> having the problem solved properly and in rare cases even being
> happy that others have not (yet) found that bug, so that their
> calculations could not work. also, too many people seem to be afraid,
> that posting a (stupid?) may have a negative effect on their
> reputation
> and thus remain "lurkers".
> 
> i have been trying to encourage people to participate more in open
> source projects for almost as long, and so far the most common
> response was: i am not a programmer/expert, i cannot do anything.
> 
> this is PLAIN WRONG. it is the newbie who has problems understanding
> and documenting while you figure out how things work, is the fastest
> and best way to learn a package properly. if you document what you
> figure it out, it is likely that another newbie will understand it,
> or from the questions of other newbies you can learn more about the
> method and look into questions, you didn't ask yourself up to now,
> but _should_ have asked. this is how i learned CPMD, and a tutorial
> can be easily created from the outcome of that. it will be even better
> if several people would "gang up" and share the workload and have some
> expert overlooking it. this would make the most out of everybody's
> time.
> 
> IMNSHO, the real trick is to be confident enough to take your time,
> pick examples that are simple enough to predict the results, do the
> calculations quickly and find out what went wrong, if you don't get
> what you expect. if you learn a craft, you don't start by doing the
> most complicated work either. you learn each technique in steps and
> _then_ move on to the more complicated work.
> 
> > > Make some tutorials or case studies, can help to debug the program
> > > and  can be
> > > a good start point for old user and new user.
> 
> those suggestions are easily made. but everybody has to stop
> saying what should be done and rather ask themselves "what can
> _I_ do?". this is why i didn't suggest to have a release (i guess
> everbody agrees on that), but rather was asking what do you all
> want to see in it? what do you think is working well enough?
> 
> >
> > That's absolutely true. But the power of the open source community is
> > mainly based on the fact that everybody
> > contributes even with a small stone to the construction of the main
> > building, under a continuous refereed work
> > (since each line (of source, tutorials, case studies, documentation)
> > you make public can in principle be double-checked
> > by trillions of people).
> > But exactly as I said previously for the release topic:
> > documentation, tutorials and case studies requires lots of
> > human power (ask Axel how much efforts he put in the CPMD
> > tutorial ;-) at the same time I think that once the
> > tutorial was made public he also received many comments about it..
> 
> yes, the CPMD stuff on the bochum servers took a lot of time,
> but it also helped to save a lot of time, since one no longer
> had to explain everything in detail. you can tell people to
> try that one out first and then come back if they have more
> questions. on top of that i would say, that i attribute to a
> large degree my current employment (and opportunities of future
> employment) to exactly those efforts. the investment of time
> has paid off in many expected and unexpected ways.
> 
> > and also possible bug fixes of things he wrote)..
> > well the point is that  human power specifically for these kind of
> > things is always highly appreciated..
> 
> the sad side of this whole business is that the turnout is always
> very low. so far only about 5% of the subscribers of the group
> have participated. i guess several are still on vacation, but...
> 
> > cp2k can become better and better if more and more people will start
> > contributing to it.. not necessarily implementing
> > new things.. also offering help, as you said, in writing a more clear
> > documentation, tutorials, case studies or offering
> > help for maintaining a release.
> 
> 
> > Sooo Sooo... what should I say more? ;-)
> 
> i cannot make any final commitment until in about a month or so,
> but due to my large experience in CVS and moving patches around
> with other packages, i would volunteer for a "release coordinator",
> i.e. i could keep an eye on changes/bugfixes in the development
> branch that may need to be carried over to the release branch,
> review bug reports and oversee the writing of a user's guide
> and a tutorial. i won't have time to do the legwork on those,
> but as stated above, that would be a perfect opportunity for
> a few newbies to gain valuable insight in cp2k with comparatively
> little extra effort _and_ demonstrate their appreciation for
> the (huge!!) effort that the other developers have put into
> the code until now. if there would be 2-3 people willing to take
> the material already available on this webserver and re-edit it
> and then take input examples provided by others or taking from
> other codes and turn them into some useful expamples, we should
> have a good chance to get something done within a few months.
> 
> as written before, the most important decision would be to
> identify features, that should be labeled as supported. i would
> recommend to not remove anything from the release version, but
> rather add a flag to check clear supported features. the input could
> have a keyword (in &GLOBAL) ENABLE_UNSUPPORTED_FEATURES which
> would be set to false by default in releases and true in developement
> versions. that would make maintenance easier and every developer of
> a subsystem can decide on a fine grained level whether a feature
> is production ready or not.
> 
> cheers,
>     axel.
> 
> >
> > Teo
> >
> > > It is only another suggestion....I hope that it is interesting
> >
> > > Ciao
> > >   Luca
> >
> 
> > 
>