Just a reminder to everyone about this note we sent out in March. yt-4.0 is an important release. A fair number of users are already using it in production work, and some of our downstream packages are more or less in somewhat of a holding pattern of sorts until it’s released (those being yt_astro_analysis, Trident, and pyXSIM, among others). It would simplify matters for these various interests immensely if yt-4.0 were released soon. For those and other reasons, it would be very helpful if we could get as much help as possible pushing this out the door in a timely fashion. The first way to help out is to try solving the open issues and PRs here related to yt-4.0: https://github.com/yt-project/yt/issues/3125 <https://github.com/yt-project/yt/issues/3125> The second way to help out is that we recommend (as we did in the previous message) that PRs be submitted that are only directly relevant to the 4.0 release until we’ve filled out that list. We definitely appreciate any and all improvements to the code and want to see all of them! Nevertheless, for the time being we would strongly prefer to prioritize developer time towards triage, review, and effort towards version 4.0, so that we can be as focused as possible until the release, for the sake of our many users. If you have the time to pitch in (many of us understandably do not!), please do!
On Mar 30, 2021, at 11:44 AM, John Zuhone <jzuhone@gmail.com> wrote:
Dear yt-dev,
The steering committee met last week to determine the operation of the yt project for the next few months until yt 4.0 is released. It is our intention that 4.0 will come out in May or early June 2021. We want to summarize here how--to ensure that 4.0 can come out in this timeline--our process will differ from our classical operations and also what will continue after the release. We are so excited by the new development that has been going on in yt, but as a project we are resource limited and need to make some difficult decisions to ensure the release happens in a timely fashion.
Until the yt 4.0 release, the steering committee recommends that project resources (PR triage time, coordinated development effort, reviews, testing support, etc.) be focused on PRs that are directly related to (1) allowing the yt-4.0 release to occur or (2) are bugs that are breaking yt or giving inconsistent/incorrect results. In practice, this means that we are asking you to hold off submitting PRs that are about style or unnecessary improvements to functionality. Otherwise, we are using our triage time to figure out whether a PR is required for the yt-4.0 release rather than diving in and moving our project forward. You are welcome to open any number of issues as placeholders for the work that you want to do rather than opening PRs. Resolving issues will be welcome after the release or during housekeeping week, depending on the content of the issue.
A few other items from the steering committee discussion:
Housekeeping week We will have a housekeeping week to focus on cleaning up the codebase. This is when we want dead code, code styling, and other PRs both submitted and merged. Housekeeping week will be on June 7-11 this year.
PR Mentorship Week This is a week that we will help get older PRs and PRs from new contributors across the finish line. PRs from new contributors are always welcome; this week is specifically for extra focused time to boost the work of new contributors. This will include dedicated time from the development community on taking over PRs or mentoring newer contributors whose PRs have been waiting a while. PR Mentorship week will be held on August 2-6 this year.
The pre-commit bot The steering committee has discussed the pre commit bot and finds that the bot actively committing to open PRs with formatting changes on push is having adverse unforeseen complications for developers. We believe the bot represents a barrier for the following reasons: • It fills the git history of larger PRs with lots of formatting commits. It is not reasonable to expect a developer or contributor to interactively rebase to get rid of these. • It requires that developers always pull from their own development branches or risk having to resolve a merge commit in order to continue their development work. • It makes changes without consent to developer and contributor work. Developers and contributors should be able to resolve formatting in their own time and individually if they wish. With this reasoning the steering committee has decided: • The pre-commit.ci bot will be deactivated on the main yt project/yt repository. • We will return to styling checks as part of our CI checks in a PR. If black, isort, or anything else is not appeased, it will fail and cannot be merged. • We will create a bot that can be called on PRs to format styling if it is requested by the PR author or a yt-project member. This can be used if a developer does not feel like performing manual changes.
As always, please remember: • All developers are human, and it takes time to submit and review PRs. Be kind in your responses to one another. • Consider the effects of changes in PRs on current developers, on users, and on downstream packages. These are all important parties in the yt-project community. • Do not create PRs that negate another contributor’s active PR. This is demotivating to the other contributor and differences in code opinion should go through the decision making process as outlined in our governance. • Please try to discuss code changes in a public channel before developing on them. • Keep discussions about code in public channels (e.g. stylistic suggestions, differences in implementation, disagreements about code, etc.etc.). This will help maintain transparency of the software development and decision-making process.
Thank you all for being such a wonderful and vibrant development community! We are looking forward to the 4.0 release and will see you on the mailing list, slack, github, etc.
The yt project steering committee