[yt-dev] reorganizing YTEPs

[Britton Smith]

Hi guys,

I left this discussion of reorganizing the YTEP index for a bit, but I'd
like to give it a little closure for now.  I've been messing around with
ways to organize the index page by YTEP type and haven't found anything
that I've been super satisfied with.  Since we're still at only a dozen
YTEPs, I'd like to leave this for now and maybe come back to this sometime
in the future.

Britton


On Tue, Apr 30, 2013 at 7:35 AM, Matthew Turk <matthewturk at gmail.com> wrote:

> Hi Britton,
>
> On Mon, Apr 29, 2013 at 10:06 AM, Britton Smith <brittonsmith at gmail.com>
> wrote:
> > Hi all,
> >
> > One of the things that came out of the yt strategy meeting last week was
> a
> > discussion of reorganizing how the YTEPs are listed.  Currently, it looks
> > like this:
> > http://ytep.readthedocs.org/en/latest/
> >
> > There are essentially two problems with this.  First, once a YTEP is
> > accepted, it is difficult to tell the status of the actual enhancement
> that
> > was proposed.  Is it being implemented?  Is it done?  Second, because we
> are
> > doing revisions in PRs, there is no listing of unaccepted YTEPs.
> >
> > For comparison, here is the enhancement proposal index for python:
> > http://www.python.org/dev/peps/
> >
> > They have categories for types (standards, information, and process) and
> > status (accepted, rejected, withdrawn, draft, etc.).  This may be
> slightly
> > overkill for us since we are only on YTEP 14 and they have hundreds.  I
> > still think some organization would be helpful.  I will have a go at that
> > and issue a PR.
> >
> > The question I have for people is with regard to process.  In order to
> have
> > statuses for the unaccepted proposals, they have to exist in some
> fashion in
> > the main repo.  How do we want to do that?  Or do we want to do that?
>  One
> > way would be to issue a PR that would include adding it to the index as
> > Draft status and have it be accepted quickly.  People can still leave
> > comments on a merged PR and the author can then issue a new one which
> moves
> > the listing to the accepted status.
>
> I like this, but I suspect that the number of comments will probably
> go down.  I think Python discusses via python-dev, but I think the PR
> process is superior for our use case since it's threaded.
>
> Maybe if we stick to the idea -- like they have -- of having a
> "rejected" status it will be easier to manaeg this?
>
> Anyway, I'm +1 on trying this out.  Thank you for addressing this, as
> well.  As we move forward we'll need to cultivate items from the YTEPs
> and move them into the docs, as well as regard them as a form of
> process documentation, and this will make both of those things easier.
>
> -Matt
>
> >
> > I'd really like to hear people's thoughts about this.  Even if we don't
> > adopt the above strategy, I'd still like to organize the accepted YTEPs
> as
> > implemented and not implemented so people can get a better idea of where
> > they might get involved.
> >
> > Britton
> >
> > _______________________________________________
> > yt-dev mailing list
> > yt-dev at lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20130517/3ff4e306/attachment.htm>