Define user interface and backend functions

[christophscheuch]

We should define functions and their parameters as much as we can before we implement everything. In this way we can keep the interface to the users consistent and avoid unnecessary renaming issues while coding.

Should be tackled after https://github.com/Teal-Insights/r-wbids/issues/5 is completed.

[christophscheuch]

Some thoughts:

• Use the verb "get" for functions that download data from API vs "list" for functions that return data that comes with the package (e.g. get_indicators() vs list_geographies())
• Use ids_ prefix to avoid potential future conflicts with wbwdi package, e.g. ids_get_debt_statistics() and ids_list_geographies()

Note that I did not implement these things yet for wbwdi, but I'll align its interface with wbids once we have reached a decision.

My proposal for the initial user interface is hence (optional arguments are NULL by default):

• ids_list_geographies(): no parameters, just returns a list of geographies that are shipped with the package (incl. standardize names).
• ids_list_series(): no parameters, just returns a list of series that are shipped with the package.
• ids_list_counterparts: no parameters, just returns a list of counterparts that are shipped with the package.
• ids_list_series_topics(): no parameters, just returns a list of series-topics combinations that are shipped with the package.
• ids_get_debt_statistics(geography_id, series_id, counterpart_id, start_year = NULL, end_year = NULL)

In the "backend", we need a perform_request() function or similar to avoid repetitive code (see here.

[christophscheuch]

Reopened the issue to use it as a input for the programming kick-off meeting.

Kick-off meeting agenda (more or less):

• Goal? Send r-wbids package to CRAN by end of November
• Roles? Who is expected to do what?
• Work packages? How do we slice the work into issues?

[t-emery]

I like the goal of sending this to CRAN by the end of November. Discussing roles & how to break up the work seems like a good agenda for tomorrow.

[t-emery]

Related to roles, here is my current thinking. We can discuss in today's meeting:

@christophscheuch,

1. I think we need your help the most with building the core data retrieval functions. @Reu-hub and I had trouble doing this on our own.
2. The other place we need your help is helping define best-practices. (function naming conventions, unit testing, documentation, GitHub etiquette etc..)

Two areas require my domain knowledge:

1. Variable discoverability: There is no out-of-the-box way to search for variables by meaningful categories (creditor type, government reporting perimeter, etc). I can build this out. This will be a huge help for users.
2. Aggregation: Our 1.0 version should showcase a few simple data aggregations. These aggregations will be different when referring to dollar amounts (sums) versus loan-terms (weighted averages). We should start with bilateral lenders: Paris Club, China, Non-Paris Club (Ex-China).

@Reu-hub and @chriscarrollsmith can help with everything else. We can figure out a good set of issues for each at today's meeting.

[chriscarrollsmith]

@Reu-hub and @chriscarrollsmith can help with everything else. We can figure out a good set of issues for each at today's meeting.

I'm happy to take on some code review and merge resolution responsibilities, especially since this will help me put together the git training videos you wanted. I'll also work some more today on the country aggregates micropackage I started.

[christophscheuch]

Next steps:

• Christoph: creates first drafts for the list and get functions defined above + rename wbwdi functions
• Chris: works on geography micro package for efficient mapping across packages
• Teal: adds linter
• Teal, Christopher & Ruben: provide code reviews for Christophs proposals
• Teal & Tsegaye: once the first functions can be used, they propose some more features for variable discoverability, transformations & aggregations