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'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
Hi Britton, On Mon, Apr 29, 2013 at 7:06 AM, Britton Smith <brittonsmith@gmail.com>wrote:
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.
This seems like a sensible approach. It would also be useful to have a meta-YTEP on the YTEP process so the whole process could be codified somehow. I could see this existing either within the PEP-0-esque YTEP you've suggested or within a new YTEP. -Nathan
Nathan, I think that's a pretty good idea. I take this conversation to a new YTEP. Britton On Apr 29, 2013 2:38 PM, "Nathan Goldbaum" <goldbaum@ucolick.org> wrote:
Hi Britton,
On Mon, Apr 29, 2013 at 7:06 AM, Britton Smith <brittonsmith@gmail.com>wrote:
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.
This seems like a sensible approach. It would also be useful to have a meta-YTEP on the YTEP process so the whole process could be codified somehow. I could see this existing either within the PEP-0-esque YTEP you've suggested or within a new YTEP.
-Nathan
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Britton, On Mon, Apr 29, 2013 at 10:06 AM, Britton Smith <brittonsmith@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@gmail.com> wrote:
Hi Britton,
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
On Mon, Apr 29, 2013 at 10:06 AM, Britton Smith <brittonsmith@gmail.com> wrote: 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (3)
-
Britton Smith -
Matthew Turk -
Nathan Goldbaum