The YTEP introduces official guidelines for the structure and procedures of the yt development team, including branches, PR acceptance, releases, and yt member status. Note, the initial bar for yt membership is being set merely to provide a base group to immediately nominate others who have made less quantifiable contributions.
Feedback is highly encouraged. I think we should get a lot of approvals before this is accepted as it governs how we operate from here on.
Update 1: Fixed all noted typos and clarified a few things that were commented on. If people agree on the criteria for initial members, then I will add the list of names, we can start work on the member list webpage, and begin nominating new members.
Update 2: The Team Structure section has been fully updated. I have not done anything with the Development Practices and Releases section yet. I would like some more feedback on the overlap between this YTEP and YTEP-0008. Specifically, where should the following issues be discussed:
major (unscheduled) releases and the criteria for releasing
the strategy for multi-person development of new features/infrastructure
I like that PRs of new functionality require 3 approvals before acceptance as well as documentation of the new features.
The member infrastructure seems sound. By my count, that means we'll have 17 members (14 of them still in the field).
I know there was some discussion of having a "core developer" group, either to act as a code steering committee, or simply to highlight these developers as having large contributions. Is there any support for something like this?
In my mind, the core developers concept has morphed into the idea of yt member status with the steering committee being the monthly meetings with representatives of the various subcomponents. Perhaps later another tier of leadership can be added if it seems necessary, but I like the idea of starting with something inclusive like this.
Hi Britton, I think that this is very nice. Some potential points that could be added if people think they should be explicitly discussed:
authorship of forthcoming yt papers:
if in the future a new paper is produced describing a new yt release, what are the requirements for coauthorship?
presentation of yt at meetings:
do we want to encourage people giving yt overview talks to post their slides in advance of the meeting to the list for feedback? (as a courtesy, since sometimes things can be overlooked, out-of-date, etc.)
what if two people want to give the yt talk at the same meeting (e.g. SciPy), perhaps the release manager for the most up-to-date release gets priority?
Michael Zingale, these are all worth discussing, authorship on future papers in particular. These should probably be discussed by yt members as a whole. I'm inclined to say we should first establish a group of yt members and then return to these items as one of our first orders of business and either write a new ytep or amend this one, but anyone else who has thoughts on this right now should share them.
Hm, these are great points. I actually would be inclined to make the standard slightly lower than membership for authorship, but I don't know how others would feel.
For the slides in advance, I think that's a good point. Same for giving talks. If we're going to talk about governance, then I think we also implicitly recognize that our appearance as a community is something that we can all have an investment in.
Hi everyone, I think this went mostly unnoticed, but I left a new comment in the PR description asking for input on the second half of the YTEP. If you did see, then sorry for being a bother, but it seems that it went under the radar.
All comments have now been implemented and I think this is ready for final review and acceptance. After some offline discussions, some text was moved from YTEP-0008 to make things consistent. Initial members have been added as well.
I just added the link to the Project Members page that will go up when Matt Turk's PR is accepted. I think if there are no more comments by the end of the day on the west coast, this should be accepted. chummels and Kacper Kowalik, you two are the last to accept. Do you have anything to add?
I like the suggestions made on list for description of contributions of each member is worthwhile, both for potentially giving credit to members for their contributions as well as providing a way for people to identify experts on certain areas of the code. I suppose it doesn't need to be described in this document, but I wanted to mention that I liked it. I know the "core member" idea isn't great for the reasons cited, but I was just trying to make sure individuals were properly credited for their contributions so as to keep all of us employed. As everyone here knows, it's not easy contributing time and effort into an effectively faceless body of work to be used by one's competitors.