search

Rdatatable / data.table

R's data.table package extends data.frame:
http://r-datatable.com
Mozilla Public License 2.0
3.6k stars 981 forks source link

Consider Enabling GitHub Discussions #5608

Open davidbudzynski opened 1 year ago

davidbudzynski commented 1 year ago

I've been paying closer attention to this repo in the last year or so and it struck me that there are hundreds of open irrelevant issues relate more to technical support rather than filing bug reports or feature requests.

Since all development for this project happens on GitHub, I think it would make sense to set the GitHub Discussions tab.

This would allow for a reduction in the ever-increasing number of issues and better engagement from the community as it could all happen on the discussions tab.

What are your thoughts?

jangorecki commented 1 year ago

If you could post some examples then it will help. Personally I prefer issues only, less places to keep track and less places to search when looking for something.

davidbudzynski commented 1 year ago

Few examples from R world would be mlr3 and quarto. It's also possible to convert issues into discussions (link) and creating issues linked to discussions (link).

I think that would help some discussions to resurface. To give an example, without reading https://github.com/Rdatatable/data.table/issues/5425 it would not occur to me that https://github.com/Rdatatable/data.table/issues/1523 was tracking all print.data.table enhancements. Because it was initially open in 2016, it got buried by new issues and it's got a poor visibility.

I think that the discussions tab would help resurface these, as the most important discussion topics could be pinned without messing up the issues tab. This could encourage people who see some of these suggestions or ideas to contribute to the project.

jangorecki commented 1 year ago

Another reason why I am against...

Actually I was as well against GH wiki, in favor of extra markdown documentation file inside the package code inst/doc. GH wiki is fortunately accessible via git interface as well so it is less relevant.

...is that we are locking ourselves into MS owned product, a company which history is not very bright. Ideally would be to keep everything in git, or git metadata (like wiki). IMO the less product specific lock-in feature that are not part of git protocol, the better. Of course we won't eliminate all. In some way it is like managing dependencies, in this case, of a project rather than a code. The less we are dependent on a particular product to run our project the better.

As the suggestion is getting stale I would like to close it. Maybe more contributors to DT code could express their opinions, or upvote/downvote comments here, so we know better if we want to proceed with this proposal.