<p dir="auto">Users should be able to get datasets returned as [Sparse]DataFrames with named columns in this day and age, for those datasets otherwise providing a Bunch with <code class="notranslate">feature_names</code>. This would be controlled with an <code class="notranslate">as_frame</code> parameter (though <code class="notranslate">return_X_y='frame'</code> would mean the common usage is more succinct).</p>
<p dir="auto">We are terrible at removing "help wanted" labels from issues that have solutions in the works. Having another label added automatically when a PR exists that claims to fix an issue would help. Or perhaps just automatically removing "help wanted" would do.</p>
<p dir="auto">Unfortunately GitHub provides little in the way of API to identify when an issue is referred to, let alone by a pr with "fixes", "closes", etc.</p>
<p dir="auto">The idea, then, would be to watch activity on the repo (initially by polling the events API; otherwise with a web hook), and when a pull request event comes in, to check if its .payload.pull_request.body contains a "fixes"-style statement, and to label the targeted issue appropriately.</p>
<p dir="auto">Firstly, the contributor (ping <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/gxyd/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/gxyd">@gxyd</a>) should check if there are existing bot apps for GitHub that can be easily configured to do this (especially to respond to events)  Otherwise this should be implemented in a separate repo and initially tested on another repo (or on itself).</p>
<p dir="auto">Extensions:</p>
<ul dir="auto">
<li>Track which PRs will close which issues in a database</li>
<li>Use that database to update the tags when a PR description is changed, or the PR is closed.</li>
<li>Record when each pr was last updated. Use this to distinguish between a "has active pr" and a "has inactive pr" label</li>
</ul>