July 11, 2009
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.
July 11, 2009
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.
July 11, 2009

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.
July 11, 2009
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.
July 14, 2009
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
July 14, 2009
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
July 14, 2009
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
July 14, 2009
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.
July 14, 2009
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
July 14, 2009
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.