Should we include TODO documents?

[IndrajeetPatil]

Inspired by @rempsyc's list: https://rempsyc.remi-theriault.com/TODOS.html

Writing such a document would be a good way to force ourselves to think as to which of the pending features are more important, and it might also provide users with a roadmap as to where we are heading (provided we include the document on the website).

OTOH, we already have GitHub issues to track feature requests and can use labels to organize them according to priority, etc., but it's not as user-friendly when it comes to garnering future roadmap.

[rempsyc]

Of course, I can't disagree with this brilliant idea hehehe 😝. I can imagine however that it could be trickier with managing 11 packages, since each one would probably have its own file (for manageability), and so it would be more maintenance work keeping all of them up to date. The organization and clarity benefits are really satisfying though. And yes, for newbies and users that read the pkgdown site (if we include it there), it's a gift. And it could (possibly) prevent some people from opening new issues if they see we are already headed there.

Also, since we write this document ourselves, it doesn't have to match issue tracking 100%, so we have the benefit of crafting the document to our exact needs and vision. We for instance could decide to add only what we consider important, stuff not in existing issues, and yes, organize it all by order of priority. It's also the only way to have a truly holistic view of future developments IMO.

[etiennebacher]

FYI it's possible to make a sort of roadmap in github issues using milestones:

[rempsyc]

Thanks, good to know @etiennebacher we should consider it. Because I have to mention that for a single-author package like rempsyc, it is easy to update the to-do list because I don't have to discuss any decision with anyone, so the benefit of opening issues for everything is smaller (and extra work). Whereas for easystats it makes sense to use the issue system because (1) it already works like that, and (2) most changes will be discussed with others. The only potential downside is that I don't know if GitHub milestones could be smoothly integrated on the pkgdown website in a nice and user-friendly way—not for us developers, but for end-users. So the question is: who do we primarily want to do this for: developers or users?

[IndrajeetPatil]

I don't think that's user-friendly, though. This expects users to familiarize themselves with GitHub and how milestones organize issues. The TODO document, OTOH, is just like any other document users can just read on the website.

[etiennebacher]

I don't know if GitHub milestones could be smoothly integrated on the pkgdown website in a nice and user-friendly way

Hmm I wonder if it's possible to use the github API (cf the dashboard) to extract issues with milestones and create a "roadmap" page on pkgdown. This is only useful if milestones are used of course

Just to explore: gh::gh("/repos/easystats/datawizard/milestones")

[mattansb]

I have been using github issues on all packages here in this manner already ^_^

Are we specifically talking about having it appear on a pkgdown page? We can add a "wishlist" tag to GH issues, and then link to this from pkgdown in the menu bar. E.g., all open "low priority" tagged issues on effect size

[rempsyc]

Last thing. Using the github issue titles might not be as user-friendly as writing it ourselves for our target audience, because the issue titles are targeted at developers, so they are not always clear because they were not written with that in mind (a few example titles from this repo: "model dashboard not lao", "Predicted values tab error", "Please make a conda metapackage!").

However, if our github integrated roadmap can use specially selected issues (milestones tags), we can be more selective in which issues we include, for example, only issues with clear and self-sufficient titles. If we can do all this (github API integration like the dashboard), once set, it would have the advantage of being automatized and relatively low maintenance. We could keep the current workflow and just add the milestone tag to issues we want to see on that to-do list as we create the issue.

[rempsyc]

(Also, nothing is preventing us from using manual to-do lists now, and as we take the time to figure out the GitHub milestone dashboard integration eventually)

[IndrajeetPatil]

TBH, this is not at all what I had in mind from a user-facing document like this.

As a user who is not too deep in the weeds about easystats, GitHub, or software development, what I would like to know from a TODO document is what's the future roadmap for the package, without getting into as much details as a GitHub issue.

For example, what remains to be done before there is a stable (1.0) release.