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 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
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 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)

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
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 next sibling 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 next sibling parent 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
prev sibling next sibling 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 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.

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 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

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
prev sibling 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

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