www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - new DIP1: DIP Template

reply Leandro Lucarella <llucax gmail.com> writes:
Hello, I just created a DIP (D Improvement Proposal) index[1] and the
first DIP (DIP1), a DIP template[2].

Here is the complete text, to make easier to discuss it:

------------------------------------------------------------------------------

= DIP1: DIP Template =

DIP:           1
Title:         DIP Template
Version:       1
Status:        Draft
Created:       2009-07-07
Last Modified: 2009-07-07
Author:        Leandro Lucarella <llucax gmail.com>

== Abstract =

This is a sample template to easily start a new DIP. DIPs can be fairly
informal for now, but at least the leading metadata should be included, and a
short abstract.

== Rationale =

Keeping track of improvement proposals is very hard and not well documented
organized. Having a template (and a process) for such proposals can improve the
situation significantly.

== Usage =

To start a new DIP you can go to Edit link and copy the source of this DIP,
then go to [DiPs DIP index] and add a new item in the list. The DIP number
should be one more than the last DIP in the index (for example, if the DIP1 is
the last DIP, your DIP should be DIP2). The link in the index should have the
form: "[DiPx DIPx (title)]: resume", where 'x' is the DIP number, 'title' is
the DIP title and 'resume' is a short description about the DIP.

Save the DIP index page and click on the '?' at the side of the new link. Now
you are editing the new DIP you just created, now paste the copied *'source*
text from this template and replace all the you need.

Remember to update the metadata at the start of the DIP, and keep it as a Draft
at the beginning. When your DIP is done, you should announce it in the News
Group for discussion, with a subject like this: '''new DIPx: title''' (where
one more time ''x'' is the DIP number and ''title'' is the DIP title).

You should always put you DIPs in the Public Domain (or a similarly permissive
license but use Public Domain unless you're very sure of what you're doing).

== Copyright =

This document has been placed in the Public Domain.

------------------------------------------------------------------------------


[1] http://www.prowiki.org/wiki4d/wiki.cgi?DiPs
[2] http://www.prowiki.org/wiki4d/wiki.cgi?DiP1

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Dentro de 30 años Argentina va a ser un gran supermercado con 15
changuitos, porque esa va a ser la cantidad de gente que va a poder
comprar algo.
	-- Sidharta Wiki
Jul 07 2009
next sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
FYI, you could have a DIP as a subpage to DiPs, which in turn could be a 
subpage to LanguageDevelopment. Personally I'd suggest a Proposal subpage 
cantaining the DIPS, which in turn hold any pages they need.

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/Proposal
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/Proposal/DIP1
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/Proposal/DIP1/
DiscussionArchive

I didn't create the pages, just examples if you want to move it. The 
internal structure isn't as important as the visual structure (how you 
get there), but I think they somewhat go hand and hand.

----

As for the DIP template, I like the idea. It lays out a very clear 
objective as to what should go into a proposal. In fact, when I get 
around to it I'll probably use it to create DIPs that have already been 
turned down.
Jul 07 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Jesse Phillips, el  8 de julio a las 02:04 me escribiste:

 FYI, you could have a DIP as a subpage to DiPs, which in turn could be a 
 subpage to LanguageDevelopment. Personally I'd suggest a Proposal subpage 
 cantaining the DIPS, which in turn hold any pages they need.
 
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/Proposal
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/Proposal/DIP1
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/Proposal/DIP1/
 DiscussionArchive


That's a good suggestion! I like it. If nobody complains about it I will
use the new structure.

BTW, I used "DiP1" as wiki page because DIP1 wasn't recognized as a wiki
page. Do you know if it's possible to use DIP1?

I'd like to use this structure:
LanguageDevel/DIPs/ (index)
LanguageDevel/DIPs/DIP1 (current version)
LanguageDevel/DIPs/DIP1/Archive (previous versions)
LanguageDevel/DIPs/DIP1/Archive/Revision1 (previous versions)
LanguageDevel/DIPs/DIP1/Archive/Revision2 (previous versions)
LanguageDevel/DIPs/DIP1/DiscussionLinks (links to discussions)

Maybe it's a little bloated for now...


 I didn't create the pages, just examples if you want to move it. The 
 internal structure isn't as important as the visual structure (how you 
 get there), but I think they somewhat go hand and hand.


BTW, can pages be moved or should I copy the contents to a new page and
then remove the old one?


 ----
 
 As for the DIP template, I like the idea. It lays out a very clear 
 objective as to what should go into a proposal. In fact, when I get 
 around to it I'll probably use it to create DIPs that have already been 
 turned down.


That would be nice. DIPs that are turned down should be kept as rejected
so people don't come over and over again suggesting the same thing. Having
the discussion about why it was turned down would be extremelly useful.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Hey you, out there on your own
Sitting naked by the phone
Would you touch me?
Jul 08 2009
next sibling parent reply Jesse Phillips <jessekphillips+d gmail.com> writes:
Leandro Lucarella Wrote:


 Jesse Phillips, el  8 de julio a las 02:04 me escribiste:

 FYI, you could have a DIP as a subpage to DiPs, which in turn could be a 
 subpage to LanguageDevelopment. Personally I'd suggest a Proposal subpage 
 cantaining the DIPS, which in turn hold any pages they need.
 
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/Proposal
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/Proposal/DIP1
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/Proposal/DIP1/
 DiscussionArchive


 
 That's a good suggestion! I like it. If nobody complains about it I will
 use the new structure.
 
 BTW, I used "DiP1" as wiki page because DIP1 wasn't recognized as a wiki
 page. Do you know if it's possible to use DIP1?


You can name the pages in whatever manner you wish, you just won't get auto
links. If you do [LanguageDevelpoment/DIP DIP] it works fine. If you want to
use spaces you can either use {{Page and Spaces}} which is the entire page
name, for renaming something you must use 2 _ [Page__and__Spaces link].

As for moving the page, the content must be move by hand, then the old page
content can be replaced with:

#REDIRECT NewLocation


 I'd like to use this structure:
 LanguageDevel/DIPs/ (index)
 LanguageDevel/DIPs/DIP1 (current version)
 LanguageDevel/DIPs/DIP1/Archive (previous versions)
 LanguageDevel/DIPs/DIP1/Archive/Revision1 (previous versions)
 LanguageDevel/DIPs/DIP1/Archive/Revision2 (previous versions)
 LanguageDevel/DIPs/DIP1/DiscussionLinks (links to discussions)


Please no. There is no reason to archive in that manner, the page edits already
have versions. If you want to archive "final" changes, then use a single
/Archive page which references as specific archived change.

My suggestion for DiscussionArchive is probably your DiscussionLinks, i.e. the
links to newsgroup posts.

Hope that helps.
Jul 08 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Jesse Phillips, el  8 de julio a las 15:31 me escribiste:

 Leandro Lucarella Wrote:
 

 Jesse Phillips, el  8 de julio a las 02:04 me escribiste:

 FYI, you could have a DIP as a subpage to DiPs, which in turn could be a 
 subpage to LanguageDevelopment. Personally I'd suggest a Proposal subpage 
 cantaining the DIPS, which in turn hold any pages they need.
 
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/Proposal
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/Proposal/DIP1
 http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/Proposal/DIP1/
 DiscussionArchive


 
 That's a good suggestion! I like it. If nobody complains about it I will
 use the new structure.
 
 BTW, I used "DiP1" as wiki page because DIP1 wasn't recognized as a wiki
 page. Do you know if it's possible to use DIP1?


 
 You can name the pages in whatever manner you wish, you just won't get
 auto links. If you do [LanguageDevelpoment/DIP DIP] it works fine. If


That's odd, I allways typed the links as [LINK The Link] and (at least in
the preview) it wasn't shown as a Wiki link. I'll try again.


 you want to use spaces you can either use {{Page and Spaces}} which is
 the entire page name, for renaming something you must use
 2 _ [Page__and__Spaces link].


I don't understand this.


 As for moving the page, the content must be move by hand, then the old
 page content can be replaced with:
 
 #REDIRECT NewLocation


Great, thanks.


 I'd like to use this structure:
 LanguageDevel/DIPs/ (index)
 LanguageDevel/DIPs/DIP1 (current version)
 LanguageDevel/DIPs/DIP1/Archive (previous versions)
 LanguageDevel/DIPs/DIP1/Archive/Revision1 (previous versions)
 LanguageDevel/DIPs/DIP1/Archive/Revision2 (previous versions)
 LanguageDevel/DIPs/DIP1/DiscussionLinks (links to discussions)


 
 Please no. There is no reason to archive in that manner, the page edits
 already have versions. If you want to archive "final" changes, then use
 a single /Archive page which references as specific archived change.


The Wiki versions are not good enough, because you might change some typo
in the DIP but don't make a version bump. Versions of DIPs are much more
important than wiki pages revisions (which are just for revision control).
I think it would be a bad idea to have both tied.


 My suggestion for DiscussionArchive is probably your DiscussionLinks,
 i.e. the links to newsgroup posts.


I know, you just gave me the idea to archive old DIP versions ;)


 Hope that helps.


It does. Thanks.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Just because you're paranoid, don't mean they're not after you.
Jul 08 2009
parent reply Jesse Phillips <jessekphillips+d gmail.com> writes:
Leandro Lucarella Wrote:


 you want to use spaces you can either use {{Page and Spaces}} which is
 the entire page name, for renaming something you must use
 2 _ [Page__and__Spaces link].


 
 I don't understand this.


http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial

Can be linked with either {{D Tutorial}} or [D__Tutorial tutorials]


 Please no. There is no reason to archive in that manner, the page edits
 already have versions. If you want to archive "final" changes, then use
 a single /Archive page which references as specific archived change.


 
 The Wiki versions are not good enough, because you might change some typo
 in the DIP but don't make a version bump. Versions of DIPs are much more
 important than wiki pages revisions (which are just for revision control).
 I think it would be a bad idea to have both tied.


If you are thinking that you would want to fix a typo in a previous DIP
version, I think this is a bad idea. A revision "snapshot" should not be a
living document. But I suppose it really isn't as horrible as my first
impression.
Jul 08 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Jesse Phillips, el  8 de julio a las 17:43 me escribiste:

 Leandro Lucarella Wrote:
 

 you want to use spaces you can either use {{Page and Spaces}} which is
 the entire page name, for renaming something you must use
 2 _ [Page__and__Spaces link].


 
 I don't understand this.


 
 http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial
 
 Can be linked with either {{D Tutorial}} or [D__Tutorial tutorials]


Ahhhh, now I get it =)


 Please no. There is no reason to archive in that manner, the page edits
 already have versions. If you want to archive "final" changes, then use
 a single /Archive page which references as specific archived change.


 
 The Wiki versions are not good enough, because you might change some typo
 in the DIP but don't make a version bump. Versions of DIPs are much more
 important than wiki pages revisions (which are just for revision control).
 I think it would be a bad idea to have both tied.


 
 If you are thinking that you would want to fix a typo in a previous DIP
 version, I think this is a bad idea. A revision "snapshot" should not be
 a living document. But I suppose it really isn't as horrible as my first
 impression.


=)

This is of course a matter of taste. I think making a version bump just
for a typo is not very nice, but other people might think otherwise.

Anyway, the fact that DIPs are in the wiki is incidental, and tomorrow
maybe they will be in bugzilla or who knows where, and I think the version
number should belong to the DIP and not to the interface used to store
/ write them.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
- Los romanos no tenían paz, loco... Necesitaban un poco de chala...
Jul 08 2009
parent Jesse Phillips <jessekphillips gmail.com> writes:
On Wed, 08 Jul 2009 19:25:28 -0300, Leandro Lucarella wrote:


 Jesse Phillips, el  8 de julio a las 17:43 me escribiste:

 Leandro Lucarella Wrote:
 

 you want to use spaces you can either use {{Page and Spaces}} which
 is the entire page name, for renaming something you must use 2 _
 [Page__and__Spaces link].


 
 I don't understand this.


 
 http://www.prowiki.org/wiki4d/wiki.cgi?D__Tutorial
 
 Can be linked with either {{D Tutorial}} or [D__Tutorial tutorials]


 
 Ahhhh, now I get it =)
 

 Please no. There is no reason to archive in that manner, the page
 edits already have versions. If you want to archive "final"
 changes, then use a single /Archive page which references as
 specific archived change.


 
 The Wiki versions are not good enough, because you might change some
 typo in the DIP but don't make a version bump. Versions of DIPs are
 much more important than wiki pages revisions (which are just for
 revision control). I think it would be a bad idea to have both tied.


 
 If you are thinking that you would want to fix a typo in a previous DIP
 version, I think this is a bad idea. A revision "snapshot" should not
 be a living document. But I suppose it really isn't as horrible as my
 first impression.


 
 =)
 
 This is of course a matter of taste. I think making a version bump just
 for a typo is not very nice, but other people might think otherwise.
 
 Anyway, the fact that DIPs are in the wiki is incidental, and tomorrow
 maybe they will be in bugzilla or who knows where, and I think the
 version number should belong to the DIP and not to the interface used to
 store / write them.


I think you may not understand my suggestion, as the DIP version would 
belong to the DIP as a reference to an wiki archive version. So the 
archive page would contain something like:

DIP 1 [...?action=archive&cmd=page&version=1.1&id=LanguageDevelopment/
DIPs/DIP1 Ver 1]
DIP 1 [...?action=archive&cmd=page&version=1.45&id=LanguageDevelopment/
DIPs/DIP1 Ver 2]

However I do concede that your method is completely reasonable.
Jul 08 2009
prev sibling parent reply Jesse Phillips <jessekphillips+d gmail.com> writes:
Leandro Lucarella Wrote:


 I'd like to use this structure:
 LanguageDevel/DIPs/ (index)
 LanguageDevel/DIPs/DIP1 (current version)
 LanguageDevel/DIPs/DIP1/Archive (previous versions)
 LanguageDevel/DIPs/DIP1/Archive/Revision1 (previous versions)
 LanguageDevel/DIPs/DIP1/Archive/Revision2 (previous versions)
 LanguageDevel/DIPs/DIP1/DiscussionLinks (links to discussions)


I have moved the existing pages. Also think at the bottom of the page should be

------
[/DIPs/DIP1/Archive DIP Archive] [/DIPs/DIP1/DiscussionLinks Discussion Links]

and then one of the following

[LanguageDevel/DIPs/Approved Approved]
[LanguageDevel/DIPs/Rejected Rejected]
[LanguageDevel/DIPs/Withdrawn Withdrawn]
[LanguageDevel/DIPs/Pending Pending]
[LanguageDevel/DIPs/Draft Draft]

Each of these pages would be a folder, which would automatically generate a
list of its sub pages.

Withdrawn is like Rejected, but not formally by a Walter

Daft is like Pending, but is not ready for review by Walter.
Jul 10 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Jesse Phillips wrote:

 (stuff)


I'm beginning to get the sense that this isn't really appropriate for
the Wiki.  Maybe once we've got the design nailed down, we should look
at putting them up somewhere where all this organisation can be
automated.  I've had some experience with Google App Engine which might
work...

Incidentally, what is the process for creating a new DIP?  I think there
needs to be at least some level of editorial control, otherwise we'll
end up with a million "indexing should start from 1" [1] DIPs.



[1] And by this, I mean it'll be a bit like the old wish list: people
will write the bare minimum necessary to suggest some poorly thought-out
idea and just post it, irrespective of previous discussion or rationale.
 We'll either end up with a VERY strange history for DIPs as we go
through and nuke the silly ones, OR we'll end up with DIP numbers in the
hundreds.
Jul 10 2009
parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Sat, 11 Jul 2009 14:22:28 +1000, Daniel Keep wrote:


 Jesse Phillips wrote:

 (stuff)


 
 I'm beginning to get the sense that this isn't really appropriate for
 the Wiki.  Maybe once we've got the design nailed down, we should look
 at putting them up somewhere where all this organisation can be
 automated.  I've had some experience with Google App Engine which might
 work...


I think the idea is to get the design nailed down and a process for using 
it. I don't know what the Google App Engine does, but the best example I 
like was the TIP

http://www.tcl.tk/cgi-bin/tct/tip
http://sourceforge.net/projects/tiprender/

If that was hosted on dsource it probably would be ok. I think the wiki 
folders kind of give us the automation we need, not very pretty though.


 Incidentally, what is the process for creating a new DIP?  I think there
 needs to be at least some level of editorial control, otherwise we'll
 end up with a million "indexing should start from 1" [1] DIPs.


I think the idea of a DIP is to get people to create a more formal 
proposal forcing them to give some extra thought.
Jul 10 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Jesse Phillips wrote:

 On Sat, 11 Jul 2009 14:22:28 +1000, Daniel Keep wrote:
 

 Jesse Phillips wrote:

 (stuff)


 I'm beginning to get the sense that this isn't really appropriate for
 the Wiki.  Maybe once we've got the design nailed down, we should look
 at putting them up somewhere where all this organisation can be
 automated.  I've had some experience with Google App Engine which might
 work...


 
 I think the idea is to get the design nailed down and a process for using 
 it. I don't know what the Google App Engine does, but the best example I 
 like was the TIP
 
 http://www.tcl.tk/cgi-bin/tct/tip
 http://sourceforge.net/projects/tiprender/
 
 If that was hosted on dsource it probably would be ok. I think the wiki 
 folders kind of give us the automation we need, not very pretty though.


Google App Engine basically lets you write a Python (and soon, Java) web
application that they serve from their servers.  The reason I suggested
it is that it gives you free hosting for smaller projects (and the DIPs
aren't likely to require a huge amount of traffic, CPU time or storage),
we can do whatever server-side processing we want, and it also gives us
authentication stuff.

The thought was to create a DIP app at, say, dip.appspot.com which lists
the DIPs, allows you to search or sort them, sends out email or RSS
updates, and lets people comment on DIPs directly, submit new ones if
they have permission, blah, blah, blah.

(The less altruistic reason is so that I can propose using
reStructuredText for the DIPs :P)


 Incidentally, what is the process for creating a new DIP?  I think there
 needs to be at least some level of editorial control, otherwise we'll
 end up with a million "indexing should start from 1" [1] DIPs.


 
 I think the idea of a DIP is to get people to create a more formal 
 proposal forcing them to give some extra thought.


The problem is that there's really no way to enforce that.  I tend to
automatically assume any freedom given to people will be abused either
maliciously or due to laziness.

Let's say someone decides that not being able to have templated virtual
methods sucks, and writes a new DIP for it.  Never mind that this is
more or less physically impossible, they could copy+paste the template,
fill it in with the minimal amount of effort, and create a new DIP.

Proposing improvements, even controversial ones, is important.  I just
worry that leaving it completely open-ended will net us something so
clogged with junk submissions that Walter won't bother looking at it.

Here's the section from PEP 1 on how you actually go about creating a
PEP: <http://www.python.org/dev/peps/pep-0001/#pep-work-flow>.
Basically, the editors act as gate keepers to ensure a minimum standard
of effort has been made.
Jul 10 2009
parent Jesse Phillips <jessekphillips gmail.com> writes:
On Sat, 11 Jul 2009 16:19:17 +1000, Daniel Keep wrote:
 

 Let's say someone decides that not being able to have templated virtual
 methods sucks, and writes a new DIP for it.  Never mind that this is
 more or less physically impossible, they could copy+paste the template,
 fill it in with the minimal amount of effort, and create a new DIP.


Yeah, but what if 5 other people want to know why virtual templeted 
methods aren't available? I mean for someone that has just come to the 
language and thinks they have the solution to all problems, they could 
easily come to the conclusion that it is because templeted methods aren't 
virtual.

That said, I don't think anyone would have a problem with a reasonable 
alternative that provides some administration. To tell you the truth, I 
think the benefit for having the moderation is that it would give people 
a roll, considering that I don't think many would work to moderate the 
DIPs on the wiki. Also a system built to do this does look better to 
those new.
Jul 11 2009
prev sibling next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
Leandro Lucarella wrote:

 Hello, I just created a DIP (D Improvement Proposal) index[1] and the
 first DIP (DIP1), a DIP template[2].
 
 Here is the complete text, to make easier to discuss it:
 
 ------------------------------------------------------------------------------
 
 = DIP1: DIP Template =
 
 DIP:           1
 Title:         DIP Template
 Version:       1
 Status:        Draft
 Created:       2009-07-07
 Last Modified: 2009-07-07
 Author:        Leandro Lucarella <llucax gmail.com>
 
 == Abstract =
 
 This is a sample template to easily start a new DIP. DIPs can be fairly
 informal for now, but at least the leading metadata should be included, and a
 short abstract.
 
 == Rationale =
 
 Keeping track of improvement proposals is very hard and not well documented
 organized. Having a template (and a process) for such proposals can improve the
 situation significantly.
 
 == Usage =
 
 To start a new DIP you can go to Edit link and copy the source of this DIP,
 then go to [DiPs DIP index] and add a new item in the list. The DIP number
 should be one more than the last DIP in the index (for example, if the DIP1 is
 the last DIP, your DIP should be DIP2). The link in the index should have the
 form: "[DiPx DIPx (title)]: resume", where 'x' is the DIP number, 'title' is
 the DIP title and 'resume' is a short description about the DIP.
 
 Save the DIP index page and click on the '?' at the side of the new link. Now
 you are editing the new DIP you just created, now paste the copied *'source*
 text from this template and replace all the you need.
 
 Remember to update the metadata at the start of the DIP, and keep it as a Draft
 at the beginning. When your DIP is done, you should announce it in the News
 Group for discussion, with a subject like this: '''new DIPx: title''' (where
 one more time ''x'' is the DIP number and ''title'' is the DIP title).
 
 You should always put you DIPs in the Public Domain (or a similarly permissive
 license but use Public Domain unless you're very sure of what you're doing).
 
 == Copyright =
 
 This document has been placed in the Public Domain.
 
 ------------------------------------------------------------------------------
 
 
 [1] http://www.prowiki.org/wiki4d/wiki.cgi?DiPs
 [2] http://www.prowiki.org/wiki4d/wiki.cgi?DiP1
 



I think this is a good idea. :) Regarding the template, I think there 
should be one more section, called "Description". Then each DIP would be 
organised as follows:

Abstract:
     Short summary of description, rationale and usage.
Description:
     Detailed description of proposal.
Rationale:
     Explanation of why proposal has been made, why the new feature
     should be included.
Usage:
     Examples, etc.

Also, each DIP should have a "Status/comments" section at the bottom 
where Walter & co. can say whether the proposal needs more 
specification, better description, etc.

-Lars
Jul 08 2009
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Lars T. Kyllingstad Wrote:


 Leandro Lucarella wrote:

 
 [1] http://www.prowiki.org/wiki4d/wiki.cgi?DiPs
 [2] http://www.prowiki.org/wiki4d/wiki.cgi?DiP1
 


 
 
 I think this is a good idea. :) Regarding the template, I think there 
 should be one more section, called "Description". Then each DIP would be 
 organised as follows:
 
 Abstract:
      Short summary of description, rationale and usage.
 Description:
      Detailed description of proposal.
 Rationale:
      Explanation of why proposal has been made, why the new feature
      should be included.
 Usage:
      Examples, etc.


I agree, but think the description section should come after usage. That should
be a more natural reading order...

Also, I think we should list the available values for status, and possibly add
sections to the DIP as it gets more mature. Off the top of my head:

Draft
• Description section optional

Stable Design
• Detailed description required. Major design changes should become a new draft
DIP.
• Reaction from Walter & Co. optional

Rejected
• Reaction from Walter & Co. required. Shouldlist specific faults

Soliciting Patches
• Implementation thought
• Submitted patches (with quality remarks about each patch)

Accepted
• Links - changeset, final docs on digitalmars.com, etc...
Jul 08 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Jason House, el  8 de julio a las 08:50 me escribiste:

 Lars T. Kyllingstad Wrote:
 

 Leandro Lucarella wrote:

 
 [1] http://www.prowiki.org/wiki4d/wiki.cgi?DiPs
 [2] http://www.prowiki.org/wiki4d/wiki.cgi?DiP1
 


 
 
 I think this is a good idea. :) Regarding the template, I think there 
 should be one more section, called "Description". Then each DIP would be 
 organised as follows:
 
 Abstract:
      Short summary of description, rationale and usage.
 Description:
      Detailed description of proposal.
 Rationale:
      Explanation of why proposal has been made, why the new feature
      should be included.
 Usage:
      Examples, etc.


 
 I agree, but think the description section should come after usage. That
 should be a more natural reading order...


About the order, I prefer the description first but I can live with the
usage first. But I think the rationale should be just after the abstract.
I think the order should be:

Abstract:
     Short summary of description, rationale and usage.
Rationale:
     Explanation of why proposal has been made, why the new feature
     should be included.
Description:
     Detailed description of proposal.
Usage:
     Examples, etc.
Other:
     Other sections as needed.

I don't even think the Usage will always be there (there could be DIPs for
removing a feature for example).


 Also, I think we should list the available values for status, and
 possibly add sections to the DIP as it gets more mature. Off the top of
 my head:
 
 Draft
 ? Description section optional
 
 Stable Design
 ? Detailed description required. Major design changes should become a new
draft DIP.
 ? Reaction from Walter & Co. optional
 
 Rejected
 ? Reaction from Walter & Co. required. Shouldlist specific faults
 
 Soliciting Patches
 ? Implementation thought
 ? Submitted patches (with quality remarks about each patch)
 
 Accepted
 ? Links - changeset, final docs on digitalmars.com, etc...  


I was thinking about the PEP statuses (to be honest I was inspired by PEPs
when doing this, I hope this doesn't make Python haters resistant to the
proposal now ;). But being a different language there could be different
needs so we can pick a new set of statuses of our own. I didn't wanted to
specify all these details for now to avoid bloat.

I think we should start with easy to write, not *too* formal proposals,
and increment the level of detail in the future, as the need comes more
evident, so we don't get too bureaucratic without reason.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
La máquina de la moneda, mirá como te queda!
	-- Sidharta Kiwi
Jul 08 2009
parent reply Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
Leandro Lucarella Wrote:


 Jason House, el  8 de julio a las 08:50 me escribiste:

 Lars T. Kyllingstad Wrote:
 

 Leandro Lucarella wrote:

 
 [1] http://www.prowiki.org/wiki4d/wiki.cgi?DiPs
 [2] http://www.prowiki.org/wiki4d/wiki.cgi?DiP1
 


 
 
 I think this is a good idea. :) Regarding the template, I think there 
 should be one more section, called "Description". Then each DIP would be 
 organised as follows:
 
 Abstract:
      Short summary of description, rationale and usage.
 Description:
      Detailed description of proposal.
 Rationale:
      Explanation of why proposal has been made, why the new feature
      should be included.
 Usage:
      Examples, etc.


 
 I agree, but think the description section should come after usage. That
 should be a more natural reading order...


 
 About the order, I prefer the description first but I can live with the
 usage first. But I think the rationale should be just after the abstract.
 I think the order should be:
 


<snip/>

I hope we can avoid format wars -- surely we're flexible enough to evaluate
DIPs without insisting on a particular order of presentation. Different
proposals may benefit from different presentations. The template is a great
starting point.

(I know the posters in this thread aren't insisting on a particular order, just
tossing out ideas.)

I think one of the strengths of creating DIPs is to keep track of proposals --
both to keep us from re-inventing the wheel and to keep good ideas from getting
lost in the NG. Some ideas that seem trivial generate a lot of posts and
occasionally descend into flame wars, while other, meatier proposals languish
just because no one responds.

I would suggest that the proposer also include, if applicable, which language
version (or which component or library, etc.) their proposal would affect, and
whether it is a breaking change.

The Java Community Process (which is very formal and glacially slow) uses a
question based format that may be helpful here too. (I mean the list of
questions -- not that we should use questions.)  One of their questions is "Why
isn't this need met by existing specifications?". Proposers might consider this
-- it could separate the bicycle shed ideas from more fundamental ones.

Paul
Jul 08 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Paul D. Anderson, el  8 de julio a las 14:04 me escribiste:

 About the order, I prefer the description first but I can live with the
 usage first. But I think the rationale should be just after the abstract.
 I think the order should be:
 


 
 <snip/>
 
 I hope we can avoid format wars -- surely we're flexible enough to
 evaluate DIPs without insisting on a particular order of presentation.
 Different proposals may benefit from different presentations. The
 template is a great starting point.


Absolutely. I think DIP format should be flexible.


 (I know the posters in this thread aren't insisting on a particular
 order, just tossing out ideas.)
 
 I think one of the strengths of creating DIPs is to keep track of
 proposals -- both to keep us from re-inventing the wheel and to keep
 good ideas from getting lost in the NG. Some ideas that seem trivial
 generate a lot of posts and occasionally descend into flame wars, while
 other, meatier proposals languish just because no one responds.
 
 I would suggest that the proposer also include, if applicable, which
 language version (or which component or library, etc.) their proposal
 would affect, and whether it is a breaking change.


Yes, that's important information too. I might add some of this
suggestions to the template. Do you think any of this should be present in
the metadata? I think maybe the target version of the language, but since
D1 is not allowed to evolve, I think the target version of the language
will always be the one in development, so I'm not sure about the utility
of that (considering that the information on in what version the DIP was
implemented will be present for Accepted DIPs).


 The Java Community Process (which is very formal and glacially slow)
 uses a question based format that may be helpful here too. (I mean the
 list of questions -- not that we should use questions.)  One of their
 questions is "Why isn't this need met by existing specifications?".
 Proposers might consider this -- it could separate the bicycle shed
 ideas from more fundamental ones.


I think that's what the Rationale is for.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
More than 50% of the people in the world have never made
Or received a telephone call
Jul 08 2009
parent Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
Leandro Lucarella Wrote:


 
 Yes, that's important information too. I might add some of this
 suggestions to the template. Do you think any of this should be present in
 the metadata? I think maybe the target version of the language, but since
 D1 is not allowed to evolve, I think the target version of the language
 will always be the one in development, so I'm not sure about the utility
 of that (considering that the information on in what version the DIP was
 implemented will be present for Accepted DIPs).
 


Yes, I think the target language version and/or component/library/tool/etc.
should be in the metadata (as they are in Bugzilla), since there are many
occasions where we're only interested in a subset of what's being discussed.

With respect to breaking changes in stable versions -- I know the party line is
not to allow them, but their proposal and discussion is often fruitful. And I
think they'll be proposed whether they're allowed or not!


 The Java Community Process (which is very formal and glacially slow)
 uses a question based format that may be helpful here too. (I mean the
 list of questions -- not that we should use questions.)  One of their
 questions is "Why isn't this need met by existing specifications?".
 Proposers might consider this -- it could separate the bicycle shed
 ideas from more fundamental ones.


 
 I think that's what the Rationale is for.
 


Yes, I agree. It's just a suggestion to get people to think about what they're
proposing. New capabilities in the language are more important (to me) than
doing old things in a new way. :-)

Paul
Jul 08 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Lars T. Kyllingstad, el  8 de julio a las 11:44 me escribiste:

 I think this is a good idea. :) Regarding the template, I think there should
be 
 one more section, called "Description". Then each DIP would be organised as 
 follows:
 
 Abstract:
     Short summary of description, rationale and usage.
 Description:
     Detailed description of proposal.
 Rationale:
     Explanation of why proposal has been made, why the new feature
     should be included.
 Usage:
     Examples, etc.


Yes, it's unclear from the text in the current DIP but the idea is that
a DIP can have as many sections are needed, but Description probably will
be in every DIP so it will be a good idea to add it.

I'll add the Description section and clarify that DIP can add new sections
as needed.


 Also, each DIP should have a "Status/comments" section at the bottom
 where Walter & co. can say whether the proposal needs more
 specification, better description, etc.


I think this can be in the NG discussion. There is already a "Status"
field/metadata. The possible statuses are not defined yet but I think that
we can use PEP statuses:
http://www.python.org/dev/peps/pep-0001/#pep-work-flow

We can add an "Incomplete state" maybe, but I think a DIP in the Draft
status is implicitly incomplete.

I will link this discussion to the DIP1 =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
JUNTAN FIRMAS Y HUELLAS POR EL CACHORRO CONDENADO A MUERTE...
	-- Crónica TV
Jul 08 2009
prev sibling next sibling parent reply Tim Matthews <tim.matthews7 gmail.com> writes:
Hi not a bad idea. Is a prowiki suitable enough as opposed to any other 
content management systems.

Some inspiration:

http://www.python.org/dev/peps/pep-0000/
http://www.tcl.tk/cgi-bin/tct/tip
http://www.erlang.org/eeps/
http://wiki.php.net/rfc
Jul 08 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Tim Matthews, el  8 de julio a las 22:41 me escribiste:

 Hi not a bad idea. Is a prowiki suitable enough as opposed to any other
content 
 management systems.


I started with the current Wiki because is what we have now. I really
don't like the current Wiki syntax, but I didn't wanted to add obstacles
to this idea because I think D is needing some kind of "standard" proposal
mechanism.

There is plenty of time in the future to change to another way to
write/maintain DIPs when needed.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
No debemos temer a la muerte, porque es la mejor recompensa de la vida.
	-- Ren & Stimpy
Jul 08 2009
prev sibling next sibling parent reply Michiel Helvensteijn <m.helvensteijn.remove gmail.com> writes:
Leandro Lucarella wrote:


 Hello, I just created a DIP (D Improvement Proposal) index[1] and the
 first DIP (DIP1), a DIP template[2].


Has the D team and/or users considered using an actual issue tracker for
this sort of thing? Something like Trac? Or the one offered by the Google
Code Hosting service? I quite like that one.

It's not that I don't like your template, but issue trackers are designed to
track bugs / feature requests / improvement proposals. They take some of
the work out of your hands that a wiki can not.

-- 
Michiel Helvensteijn
Jul 08 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Michiel Helvensteijn, el  8 de julio a las 21:27 me escribiste:

 Leandro Lucarella wrote:
 

 Hello, I just created a DIP (D Improvement Proposal) index[1] and the
 first DIP (DIP1), a DIP template[2].


 
 Has the D team and/or users considered using an actual issue tracker for
 this sort of thing? Something like Trac? Or the one offered by the Google
 Code Hosting service? I quite like that one.
 
 It's not that I don't like your template, but issue trackers are designed to
 track bugs / feature requests / improvement proposals. They take some of
 the work out of your hands that a wiki can not.


D already have a bugzilla instance. I picked the Wiki because it's
a little better for a proposal that's composed of various sections, code
examples, etc. I think a bug tracker is a little restricted for this.

But you are right that it's much harder to keep track of the proposal if
they are on the wiki. Maybe they should have an associated bug, so people
can subscribe to them, etc. But again, this is just the begining of the
begining. I'll see how this works first and then improve it as needed.

Maybe we set up an excelent DIP process and tools and then Walter don't
even look at them =/

BTW, Walter what do you think about this. Are you willing to look at it or
should I drop it now and stop wasting my time? =)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Qué sabía Galileo de astronomía, Mendieta! Lo que pasa es que en este
país habla cualquiera.
	-- Inodoro Pereyra
Jul 08 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
Leandro Lucarella, el  8 de julio a las 17:19 me escribiste:

 Michiel Helvensteijn, el  8 de julio a las 21:27 me escribiste:

 Leandro Lucarella wrote:
 

 Hello, I just created a DIP (D Improvement Proposal) index[1] and the
 first DIP (DIP1), a DIP template[2].


 
 Has the D team and/or users considered using an actual issue tracker for
 this sort of thing? Something like Trac? Or the one offered by the Google
 Code Hosting service? I quite like that one.
 
 It's not that I don't like your template, but issue trackers are designed to
 track bugs / feature requests / improvement proposals. They take some of
 the work out of your hands that a wiki can not.


 
 D already have a bugzilla instance. I picked the Wiki because it's
 a little better for a proposal that's composed of various sections, code
 examples, etc. I think a bug tracker is a little restricted for this.
 
 But you are right that it's much harder to keep track of the proposal if
 they are on the wiki. Maybe they should have an associated bug, so people
 can subscribe to them, etc. But again, this is just the begining of the
 begining. I'll see how this works first and then improve it as needed.
 
 Maybe we set up an excelent DIP process and tools and then Walter don't
 even look at them =/
 
 BTW, Walter what do you think about this. Are you willing to look at it or
 should I drop it now and stop wasting my time? =)


Well, I wasted my time one more time. I've updated the DIP1 with the
suggestions gathered in this thread and bumped version to 2:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1

I've added a Description section and a Links: meta-data (I think a whole
wiki page for links can be too much).

The old version is archived in:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP1/Archive/Version1

Thanks to Jesse for improving the Wiki structure and all the people that
made suggestions.

Walter, I would *really* like to know if you plan to take DIPs seriously,
I don't think DIPs will be useful and taken seriously by the community
without some kind of "official" support.

Thanks.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Nos retiramos hasta la semana que viene reflexionando sobre nuestras
vidas: "Qué vida de mier'... Qué vida de mier'!"
	-- Sidharta Kiwi
Jul 14 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:

 Walter, I would *really* like to know if you plan to take DIPs seriously,
 I don't think DIPs will be useful and taken seriously by the community
 without some kind of "official" support.


I personally want to take DIP seriously and write a couple myself. My 
understanding is that Walter is interested too.

Andrei
Jul 14 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 14 de julio a las 10:10 me escribiste:

 Leandro Lucarella wrote:

Walter, I would *really* like to know if you plan to take DIPs seriously,
I don't think DIPs will be useful and taken seriously by the community
without some kind of "official" support.


 
 I personally want to take DIP seriously and write a couple myself. My 
 understanding is that Walter is interested too.


That's really nice to hear. Thanks.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Borrowing money from a friend is like having sex. It just completely changes
the relationship.
	-- George Constanza
Jul 14 2009
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
A nice idea; however, my feeling is that there are too many places for 
proposing D features.  At the moment, feature proposals are split between:

- the newsgroups
- the eigenpoll - http://all-technology.com/eigenpolls/dwishlist/
- the wiki - http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList
- Bugzilla
- and now, DIPs

What does this achieve that the others don't?  I think what we need is 
to consolidate all the still-open feature proposals from these various 
systems into something that achieves the best of all five worlds.

Maybe this new system could cut it, if we add:

- a space in which to discuss the proposals
- possibly a voting system

But these are both things that Bugzilla already has.  Our Bugzilla 
doesn't, however, have:

- a standard form for feature proposals (though this could be added 
using a Bugzilla template)
- the ability to change a proposal after it's been submitted

Thoughts?

Stewart.
Jul 14 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Stewart Gordon wrote:

 A nice idea; however, my feeling is that there are too many places for 
 proposing D features.  At the moment, feature proposals are split between:
 
 - the newsgroups
 - the eigenpoll - http://all-technology.com/eigenpolls/dwishlist/
 - the wiki - http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList
 - Bugzilla
 - and now, DIPs
 
 What does this achieve that the others don't?


I think the eigenpoll is just a bitzombie. The newsgroup lacks 
structure; messages come and go. Bugzilla is ok for discussions but bot 
very good for collaboratively maintaining a structured and formatted 
document.


 I think what we need is 
 to consolidate all the still-open feature proposals from these various 
 systems into something that achieves the best of all five worlds.


That's a great idea looking for a taker...


Andrei
Jul 14 2009
prev sibling next sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Stewart Gordon, el 14 de julio a las 18:39 me escribiste:

 A nice idea; however, my feeling is that there are too many places for
 proposing D features.  At the moment, feature proposals are split
 between:
 
 - the newsgroups
 - the eigenpoll - http://all-technology.com/eigenpolls/dwishlist/
 - the wiki - http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList
 - Bugzilla
 - and now, DIPs
 
 What does this achieve that the others don't?


I didn't used the poll because is way too informal and brief. I think the
newsgroups *are* part of the DIPs, I suggested doing all the discussion in
the NG. I didn't knew about the FeatureRequestList wiki page, I'm sorry
about that, but I still think it's too informal too. I think DIP can be
seen as a more formal version of the same thing there.

As I said in other mail, I think Bugzilla could be a good choice, but it's
a little too restricted to write a proposal because of the lack of format;
and because proposals get lost in a sea of bugs. I guess this can be
addressed doing a meta-bug as an index for proposals or something, but
I think that separating bugs and proposals is a good thing.


 I think what we need is to consolidate all the still-open feature
 proposals from these various systems into something that achieves the
 best of all five worlds.


Agree.


 Maybe this new system could cut it, if we add:
 
 - a space in which to discuss the proposals


I think the best place for discussion is the NG.


 - possibly a voting system


I'm not *that* convinced about voting, I think voting should be done only
when no consensus is achieved, and that should be rare cases. I'll tackle
that when the need comes.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Long you live and high you fly
And smiles you'll give and tears you'll cry
And all you touch and all you see
Is all your life will ever be.
Jul 14 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Leandro Lucarella wrote:

 (stuff)


How about this?

The newsgroups are for discussion.  This includes introducing new ideas
and discussing new ones.

The DIPs are for formally recording a concrete proposal which has shown
interest from the D community.  It should include rationale, examples,
links to important discussions on the newsgroups, etc.

Bugzilla is for formally recording implementation defects.  This
includes tracking the implementation of a DIP which has been accepted.

In essence, the newsgroups are informal discussion, the DIPs are formal,
subjective issue tracking and bugzilla is for formal, objective issue
tracking.

With that sort of setup, ideas for improving the language would start in
the NG.  Once the idea has been fleshed out, someone steps up to
champion the issue and takes responsibility for the DIP.  The DIP then
records the formal description of the idea, links to NG threads, etc.
If it gets accepted by The Grand Councilâ„¢ [1], appropriate bugzilla
issues are opened and linked.

Sound acceptable?


[1] Being whoever actually has commit permission to the respective part
of the toolchain/libraries/etc.  I'd imagine that for compiler issues,
this would be Walter, Don, the LDC gang; for standard library issues:
Andrei, Sean, the top Tango folks (let's all play nice!).  Or something
to that effect.
Jul 15 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Daniel Keep, el 15 de julio a las 17:57 me escribiste:

 
 
 Leandro Lucarella wrote:

 (stuff)


 
 How about this?
 
 The newsgroups are for discussion.  This includes introducing new ideas
 and discussing new ones.
 
 The DIPs are for formally recording a concrete proposal which has shown
 interest from the D community.  It should include rationale, examples,
 links to important discussions on the newsgroups, etc.
 
 Bugzilla is for formally recording implementation defects.  This
 includes tracking the implementation of a DIP which has been accepted.
 
 In essence, the newsgroups are informal discussion, the DIPs are formal,
 subjective issue tracking and bugzilla is for formal, objective issue
 tracking.
 
 With that sort of setup, ideas for improving the language would start in
 the NG.  Once the idea has been fleshed out, someone steps up to
 champion the issue and takes responsibility for the DIP.  The DIP then
 records the formal description of the idea, links to NG threads, etc.
 If it gets accepted by The Grand Councilâ„¢ [1], appropriate bugzilla
 issues are opened and linked.
 
 Sound acceptable?


Sounds good to me.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Cuando intenté arrimarle mi brazo
Se puso a hablar de Miller, de Anais Nin y Picasso
Y si osaba intentar robarle un beso
Se ponía a leer de Neruda unos versos
Me hizo mucho mal la cumbiera intelectual
Jul 15 2009
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Daniel Keep wrote:
<snip>

 How about this?
 
 The newsgroups are for discussion.  This includes introducing new ideas
 and discussing new ones.
 
 The DIPs are for formally recording a concrete proposal which has shown
 interest from the D community.  It should include rationale, examples,
 links to important discussions on the newsgroups, etc.


<snip>

So essentially, one first discusses a feature proposal on the newsgroups 
(or, occasionally, on Bugzilla) and then, once it's got somewhere, 
creates a DIP.  And then, possibly, the newsgroup discussion continues.

What about ideas that have just fallen on deaf ears the first time they 
  were proposed?  I have a few such things that I'd like to refloat at 
some point....

Stewart.
Jul 16 2009
prev sibling parent reply Jesse Phillips <jessekphillips+d gmail.com> writes:
Stewart Gordon Wrote:


 A nice idea; however, my feeling is that there are too many places for 
 proposing D features.  At the moment, feature proposals are split between:
 
 - the newsgroups
 - the eigenpoll - http://all-technology.com/eigenpolls/dwishlist/
 - the wiki - http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList
 - Bugzilla
 - and now, DIPs


You forgot the peeves

http://www.prowiki.org/wiki4d/wiki.cgi?PendingPeeves


 What does this achieve that the others don't?  I think what we need is 
 to consolidate all the still-open feature proposals from these various 
 systems into something that achieves the best of all five worlds.


It gives u place to write thought out proposals that can be accepted, rejected,
and revised.

And most importantly, it is a fresh/clean start which fits nicely into the new
site layout. And you are correct, consolidation is needed. A clean board makes
this easier. Sadly it as a lot of work to move the old into a new formal
environment. I will probably add my share, but a issue for me is that I am not
knowledgeable on many of the requests to fill in details... then to top it off
if I do create them I'll be the one responsible to track things relating to
them.

The main hope is that this will provide a way to official and consolidated
statements as to when and if a feature will be accepted. It would be nice if
Walter were to give an official statement on the existing DIPs so as to create
more incentive to formalize existing ideas: 

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#FutureDirections
Jul 15 2009
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Jesse Phillips wrote:

 Stewart Gordon Wrote:
 

 A nice idea; however, my feeling is that there are too many places for 
 proposing D features.  At the moment, feature proposals are split between:

 - the newsgroups
 - the eigenpoll - http://all-technology.com/eigenpolls/dwishlist/
 - the wiki - http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList
 - Bugzilla
 - and now, DIPs


 
 You forgot the peeves
 
 http://www.prowiki.org/wiki4d/wiki.cgi?PendingPeeves


<snip>

That isn't a place for proposing D features.  But that page is stale.  I 
guess I'll just have to see what I can do with it....

Stewart.
Jul 16 2009
parent Jesse Phillips <jessekphillips gmail.com> writes:
On Thu, 16 Jul 2009 17:17:38 +0100, Stewart Gordon wrote:


 You forgot the peeves
 
 http://www.prowiki.org/wiki4d/wiki.cgi?PendingPeeves


 <snip>
 
 That isn't a place for proposing D features.  But that page is stale.  I
 guess I'll just have to see what I can do with it....
 
 Stewart.


Sorry, wrong link...

http://www.prowiki.org/wiki4d/wiki.cgi?DCP_Template

:P
Jul 17 2009