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

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.

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.

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

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

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

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.

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

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.

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.