1. Process
Hi all
Recently Rob posted suggesting (in effect) that the people who put proposals for
change should take charge of following them up. Several have expressed varying
levels of frustration or confusion with this process, or lack of it.
I'm going to take up Rob's idea in relation to these proposals - sequence of
integer, typing elements of a sequence-object within a type block, and aliasing
elements within a type block. I didn't have anything to do with the first thread,
but it's related to the others and no one is owning it.
If the community doesn't want me to do this, please feel free to speak up. I
won't mind.
There seemed to be enough common ground in these to warrant a vote. I will go
through the threads and try to get a couple of candidates (concrete syntax) for
each that can be voted on. I'll ignore my own comments and ideas and look for
common ground among other contributors. One variation for each may be too few
(and too hard to choose which one). More than 2 or 3 may just split the vote
indecisively.
I'll simply act as the manager of the process.
It may take me a few days, but I'll get there. I'm not acquainted with what
documentation exists on the site already, but I have in mind that all decisions,
positive or negative, should be recorded - so there'll be a TODO list (for
successful proposals) and a REJECT list (for unsuccessful ones). The reject list
will avoid repeated ventilation of the same issues - not that anything is set in
stone.
In some of the threads, people might not have contributed before for reasons
other than disinterest. Since I'll be using the threads to make selections, feel
free to wade in now. Preferably you could post to the relevant thread, not this
thread.
Cheers all
Peter Robinson
2. Re: Process
Peter Robinson wrote:
> Recently Rob posted suggesting (in effect) that the people who put proposals
> for change should take charge of following them up. Several have expressed
> varying
> levels of frustration or confusion with this process, or lack of it.
>
> I'm going to take up Rob's idea in relation to these proposals - sequence of
> integer, typing elements of a sequence-object within a type block, and
> aliasing
> elements within a type block. I didn't have anything to do with the first
> thread,
> but it's related to the others and no one is owning it.
>
> If the community doesn't want me to do this, please feel free to speak up. I
> won't mind.
>
> There seemed to be enough common ground in these to warrant a vote. I will go
> through the threads and try to get a couple of candidates (concrete syntax)
> for each that can be voted on. I'll ignore my own comments and ideas and look
> for common ground among other contributors. One variation for each may be too
> few (and too hard to choose which one). More than 2 or 3 may just split the
> vote indecisively.
>
> I'll simply act as the manager of the process.
>
> It may take me a few days, but I'll get there. I'm not acquainted with what
> documentation exists on the site already, but I have in mind that all
> decisions,
> positive or negative, should be recorded - so there'll be a TODO list (for
> successful
> proposals) and a REJECT list (for unsuccessful ones). The reject list will
> avoid
> repeated ventilation of the same issues - not that anything is set in stone.
>
> In some of the threads, people might not have contributed before for reasons
> other than disinterest. Since I'll be using the threads to make selections,
> feel free to wade in now. Preferably you could post to the relevant thread,
> not this thread.
That's fine with me. Thanks.
I've been busy lately setting up my new dual-core Vista computer,
and preparing 3.1.1. Every now and then, I'd like to see a
clear proposal that I can think about. I'm sure others would too.
With the flurry of ideas that are tossed around on this
forum, I think many people don't have time to keep up,
and assume anyway that nothing will ever be decided, so why
bother trying to follow the discussion.
A concrete proposal, or package of related proposals
that can be voted on separately, might help focus people's minds.
With software being so flexible, it may be hard to
immediately come to an agreement on all the details,
so maybe we'll need to have some sort of "vote in principle"
followed by a vote on some of the important details.
Of course, down at a certain level of detail you just have to
trust the developer(s) who are going to actually do the work.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Process
Robert Craig wrote:
>
> Peter Robinson wrote:
> > Recently Rob posted suggesting (in effect) that the people who put proposals
> > for change should take charge of following them up. Several have expressed
> > varying
> > levels of frustration or confusion with this process, or lack of it.
> >
> > I'm going to take up Rob's idea in relation to these proposals - sequence of
> > integer, typing elements of a sequence-object within a type block, and
> > aliasing
> > elements within a type block. I didn't have anything to do with the first
> > thread,
> > but it's related to the others and no one is owning it.
> >
> > If the community doesn't want me to do this, please feel free to speak up. I
> > won't mind.
> >
> > There seemed to be enough common ground in these to warrant a vote. I will
> > go
> > through the threads and try to get a couple of candidates (concrete syntax)
> > for each that can be voted on. I'll ignore my own comments and ideas and
> > look
> > for common ground among other contributors. One variation for each may be
> > too
> > few (and too hard to choose which one). More than 2 or 3 may just split the
> > vote indecisively.
> >
> > I'll simply act as the manager of the process.
> >
> > It may take me a few days, but I'll get there. I'm not acquainted with what
> > documentation exists on the site already, but I have in mind that all
> > decisions,
> > positive or negative, should be recorded - so there'll be a TODO list (for
> > successful
> > proposals) and a REJECT list (for unsuccessful ones). The reject list will
> > avoid
> > repeated ventilation of the same issues - not that anything is set in stone.
> >
> > In some of the threads, people might not have contributed before for reasons
> > other than disinterest. Since I'll be using the threads to make selections,
> > feel free to wade in now. Preferably you could post to the relevant thread,
> > not this thread.
>
> That's fine with me. Thanks.
>
> I've been busy lately setting up my new dual-core Vista computer,
> and preparing 3.1.1. Every now and then, I'd like to see a
> clear proposal that I can think about. I'm sure others would too.
>
> With the flurry of ideas that are tossed around on this
> forum, I think many people don't have time to keep up,
> and assume anyway that nothing will ever be decided, so why
> bother trying to follow the discussion.
> A concrete proposal, or package of related proposals
> that can be voted on separately, might help focus people's minds.
>
> With software being so flexible, it may be hard to
> immediately come to an agreement on all the details,
> so maybe we'll need to have some sort of "vote in principle"
> followed by a vote on some of the important details.
> Of course, down at a certain level of detail you just have to
> trust the developer(s) who are going to actually do the work.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Voting on an issue may require, to try getting all pros and cons, checking whole
threads, some of them possibly old.
The Euforum search engine searches through all messages, but the format may not
be suitable, since posts are not on individual pages - you cannot reply from a
quoted post there, unless it still displays i EuForum - the link may be really
hard to spot.
EuForum presents posts on individual pages, but the oldest available post is 8
days old or even less - this may improve some day -, which may not be enough for
irregular lurkers. However, it is the first place where new posts are available.
Topica's web interface shows all messages from Jan 25, 2001 on individual pages,
but may lag a couple days behind EuForum.
Does anyone have an idea how to give people who usually don't post, notice that
decisions which govern the language may be taken here, so that they can chime in
or at least stay tuned?
Also, given that the voters are quite few compared to real life cases, how will
the significance of a vote result be assessed?
HTH
CChris
4. Re: Process
Robert Craig wrote:
>
> Peter Robinson wrote:
> > Recently Rob posted suggesting (in effect) that the people who put proposals
> > for change should take charge of following them up.
> Every now and then, I'd like to see a
> clear proposal that I can think about. I'm sure others would too.
>
> With the flurry of ideas that are tossed around on this
> forum, I think many people don't have time to keep up,
> and assume anyway that nothing will ever be decided, so why
> bother trying to follow the discussion.
> A concrete proposal, or package of related proposals
> that can be voted on separately, might help focus people's minds.
>
> With software being so flexible, it may be hard to
> immediately come to an agreement on all the details,
> so maybe we'll need to have some sort of "vote in principle"
> followed by a vote on some of the important details.
> Of course, down at a certain level of detail you just have to
> trust the developer(s) who are going to actually do the work.
>
From the point of view of a less experienced programmer I often see useful
looking proposals here but all too often they get bogged down in discussion of
their finer points and just peter out. i.e on the Euphoria Standard Library it
seemed that all the time was spent discussing how to document the routines and no
(or very few) routines were every actually written, and then it died out.
I feel the main need is for a good set of 'standard' files, Its easy for any new
user to become very confused when looking in the archive for includes for a
specific task as there are often so many choices there it's difficult to decide
which is best to use.
It maybe there should be seperate strands to EUs development. One strand dealing
with improvements and extensions to the core library (which I would love to see)
and another grouping together the best include files for specific tasks.. There
would probably be crossover between these, where a change is suggested to the
core which proves not to be practical, but which could be simulated using normal
routines. As always there would be multiple ways of writing this, but once the
best has been decided it should be added to the 'ESL' and I would further suggest
an extra search option in the Archive just to list these recommended library
routines...
As the saying goes, there are always several ways to 'skin a cat' but I would
rather just use the most efficient way the first time and not have to spend time
trying out every method!
Of course feel free to ignore all this as the pointless ramblings of a simple EU
user 
Regards PeteS
5. Re: Process
Pete Stoner wrote:
>
> Robert Craig wrote:
> >
> > Peter Robinson wrote:
> > > Recently Rob posted suggesting (in effect) that the people who put
> > > proposals
> > > for change should take charge of following them up.
> > Every now and then, I'd like to see a
> > clear proposal that I can think about. I'm sure others would too.
> >
> > With the flurry of ideas that are tossed around on this
> > forum, I think many people don't have time to keep up,
> > and assume anyway that nothing will ever be decided, so why
> > bother trying to follow the discussion.
> > A concrete proposal, or package of related proposals
> > that can be voted on separately, might help focus people's minds.
> >
> > With software being so flexible, it may be hard to
> > immediately come to an agreement on all the details,
> > so maybe we'll need to have some sort of "vote in principle"
> > followed by a vote on some of the important details.
> > Of course, down at a certain level of detail you just have to
> > trust the developer(s) who are going to actually do the work.
> >
>
> From the point of view of a less experienced programmer I often see useful
> looking proposals here but all too often they get bogged down in discussion
> of their finer points and just peter out. i.e on the Euphoria Standard Library
> it seemed that all the time was spent discussing how to document the routines
> and no (or very few) routines were every actually written, and then it died
> out.
Hi PeteS,
All these things ("very few", "peter out", etc etc)
may be a good sign -- there is already almost nothing
to do with Euphoria, it is mature enough and is almost
perfect as it is just now.
So don't worry be happy!
If the program works OK, do not touch it, touch wood,
if you want to touch something anyway. 
[snip]
Good Luck to All!
Regards,
Igor Kachan
kinz at peterlink.ru
