PyFixest 1.0.0

[s3alfisc]

If and when should we bump PyFixest's version to 1.0.0, to signal API stability? Is there actual value in doing so?

I believe that PyFixest's feols() and fepois() APIs are mature - I do not plan to introduce any changes that go beyond adding new function arguments. This is not 100% true for all the methods: e.g. the naming conventions are somewhat inconsistent. ritest() asks for reps, wildboottest wants to have B, and confint wants nboot to specify the number of iterations. There is also inconsistent usage of alpha vs levels across functions. Here I think I should soft-deprecate some arguments in favor of consistent naming.

I'd also have to review the Difference-in-Differences APIs, for example, the event_study() function requires an update regarding it's handling of dates.

One strategy could consist of going through all the methods & to unify (and soft deprecate) naming conventions. Before releasing 1.0.0, I'd also like to implement the numpy API Apoorva @apoorvalal has suggested.

Did I miss anything? And is there even value in releasing a 1.0.0 version? More generally, would there be value in sketching out a development plan? @juanitorduz

[juanitorduz]

Hey! Here are some comments:

And is there even value in releasing a 1.0.0 version?

Yes, this usually means API stability. But there is no rush! For scikit-learn, this took years ;)

More generally, would there be value in sketching out a development plan?

Yes! Especially if we can organize the plan in issues with labels (e.g., good first issue) and release milestones. We use GitHub Projects in other projects, which works quite well with a simple Kanban board. For example, we could create such projects for core methods, documentation and code style.

[s3alfisc]

But there is no rush!

Ok, good. Then I'll put this aside =) Just checked the scikit-learn release history, 1.0.0 indeed took forever!

Yes! Especially if we can organize the plan in issues with labels (e.g., good first issue) and release milestones. We use GitHub Projects in other projects, which works quite well with a simple Kanban board. For example, we could create such projects for core methods, documentation and code style.

Ok, this is super valuable feedback. I'll then take a closer look at GitHub Projects over the long weekend & will think about "things to do" and how they might all fit together. I'll show you a first draft of it once I have something at hand. =)

[s3alfisc]

I've now created a lot of different smaller and larger issues & have tried to sketch out how to tackle the problem. Most importantly I think that there are many, many good first issues: link. @juanitorduz do you know of a good way / good strategy to find new collaborators? For example, I could try to organize a community call to discuss the roadmap and provide an introduction to the codebase, or, maybe simpler, could just advertise the "good first issues" on social media (twitter and linkedin).

[juanitorduz]

do you know of a good way / good strategy to find new collaborators? For example, I could try to organize a community call to discuss the roadmap and provide an introduction to the codebase, or, maybe simpler, could just advertise the "good first issues" on social media (twitter and LinkedIn).

Getting new contributors is a difficult (but not impossible) task. I think having self-contained "good first issues," as you have done, is a great step! I think pushing this in social media would be helpful. About the community :)

It would be interesting to attract economists from academic profiles ... maybe some PhD students, postdocs, or even professors can help us spread the word?

[s3alfisc]

I've tried myself on another round of marketing on twitter =)

[apoorvalal]

Missed this when it first started; Yeah 1.0 seems like a pretty monumental release to hit (which then comes with norms about how infrequently the API will change, etc), so I don't see any hurry there.