feedback

[sckott]

thoughts on what we have so far? https://github.com/ropensci/devroadmap#devroadmap

@ropensci/leadership @danielskatz

the format is based sorta on the jupyter roadmap repo.

i started with 2 pkgs i know well - just as a start to dial in the format we want to use

• anything to change about the roadmap document? be less specific / more specific, something else
• do yo think we still need something additional to this repo?
• i figure we don't talk here about anything in ropenscilabs account since that is by definition in beta stage pkgs

[cboettig]

Just from my perspective this looks more detailed / low-level than I had in mind. This largely recapitulates information we can already see by looking at the milestones page for each repo.

In some ways, I think we might think of a repo as the smallest unit of organization for roadmap, (rather than an issue in a repo, as waffle.io does and as we have here). With 249 different public repos in ropensci org, another 69 in ropenscilabs, and 12 more rosadmin, my first challenge is getting the big picture of ropensci dev map is just knowing what repo to start with.

Splitting things out into three different organizations has definitely helped, and maybe that's the highest level where we might start with the roadmap: i.e. how is development effort divided between developing new stuff vs maintaining / improving existing stuff? Knowing that we could better evaluate what are weaknesses are (i.e. maybe hiring more help to address maintenance could free more time for new stuff. Or maybe we don't spend enough time improving existing packages.)

At the next level down, perhaps there's a way to put large groups of repos on the roadmap. For instance, repos that are essentially mothballed or deprecated in favor of something better (RMendeley, maybe treebase), repos which are stable & maintained but unlikely to get anything new, and repos which are still under active development. (I'm spit-balling here, a different grouping might be better).

It would also be helpful I think to classify repos not just by status, but by topic area, as we do on the website. This would help see if we are allocating most of our effort to developing API wrappers, database backends, literature mining tools, data publication tools, or something else.

Perhaps a separate issue from the dev road map, but I could almost use a road map that describes current and future objectives over all the myriad repos that are not R packages but are more admin, events, etc.

[danielskatz]

I was struggling to comment on the roadmap, and now see that Carl did a wonderful job of expressing what I was thinking but was unable to express.

Dan

On Jun 15, 2016, at 23:19, Carl Boettiger notifications@github.com<mailto:notifications@github.com> wrote:

Just from my perspective this looks more detailed / low-level than I had in mind. This largely recapitulates information we can already see by looking at the milestones page for each repo.

In some ways, I think we might think of a repo as the smallest unit of organization for roadmap, (rather than an issue in a repo, as waffle.iohttp://waffle.io does and as we have here). With 249 different public repos in ropensci org, another 69 in ropenscilabs, and 12 more rosadmin, my first challenge is getting the big picture of ropensci dev map is just knowing what repo to start with.

Splitting things out into three different organizations has definitely helped, and maybe that's the highest level where we might start with the roadmap: i.e. how is development effort divided between developing new stuff vs maintaining / improving existing stuff? Knowing that we could better evaluate what are weaknesses are (i.e. maybe hiring more help to address maintenance could free more time for new stuff. Or maybe we don't spend enough time improving existing packages.)

At the next level down, perhaps there's a way to put large groups of repos on the roadmap. For instance, repos that are essentially mothballed or deprecated in favor of something better (RMendeley, maybe treebase), repos which are stable & maintained but unlikely to get anything new, and repos which are still under active development. (I'm spit-balling here, a different grouping might be better).

It would also be helpful I think to classify repos not just by status, but by topic area, as we do on the website. This would help see if we are allocating most of our effort to developing API wrappers, database backends, literature mining tools, data publication tools, or something else.

Perhaps a separate issue from the dev road map, but I could almost use a road map that describes current and future objectives over all the myriad repos that are not R packages but are more admin, events, etc.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/ropensci/devroadmap/issues/1#issuecomment-226384678, or mute the threadhttps://github.com/notifications/unsubscribe/ACx2NXGnwghEV8yX1ODnp6s7PKkK18brks5qMM7TgaJpZM4I24kI.

[sckott]

Just from my perspective this looks more detailed / low-level than I had in mind. This largely recapitulates information we can already see by looking at the milestones page for each repo. In some ways, I think we might think of a repo as the smallest unit of organization for roadmap, (rather than an issue in a repo, as waffle.io does and as we have here). With 249 different public repos in ropensci org, another 69 in ropenscilabs, and 12 more rosadmin, my first challenge is getting the big picture of ropensci dev map is just knowing what repo to start with.

If a repo is the unit of organization, what does one talk about for each repo here? Different packages loosely fit into higher level categories (e.g., API wrappers), but they don't all contribute to some larger tool (as do smaller projects within Jupyter). So I'm just not sure what we'd do with a roadmap when we're not discussing what's happening with the individual packages? I suppose we could simply put an estimated date for when a package goes to CRAN, is stable, etc.? In previous grants we've discussed areas of concentration (e.g., text mining packages), so I suppose we could talk about a "roadmap" for that level of organization?

Splitting things out into three different organizations has definitely helped, and maybe that's the highest level where we might start with the roadmap: i.e. how is development effort divided between developing new stuff vs maintaining / improving existing stuff? Knowing that we could better evaluate what are weaknesses are (i.e. maybe hiring more help to address maintenance could free more time for new stuff. Or maybe we don't spend enough time improving existing packages.)

That seems useful to think about effort towards maintenance/improvements vs. new things. That distinction is a bit hard with most API wrappers though as we're constantly changing those pkgs to keep up with web APIs changes.

At the next level down, perhaps there's a way to put large groups of repos on the roadmap. For instance, repos that are essentially mothballed or deprecated in favor of something better (RMendeley, maybe treebase), repos which are stable & maintained but unlikely to get anything new, and repos which are still under active development. (I'm spit-balling here, a different grouping might be better).

Agreed, that's helpful

It would also be helpful I think to classify repos not just by status, but by topic area, as we do on the website. This would help see if we are allocating most of our effort to developing API wrappers, database backends, literature mining tools, data publication tools, or something else.

Agreed, topic areas is helpful.

Perhaps a separate issue from the dev road map, but I could almost use a road map that describes current and future objectives over all the myriad repos that are not R packages but are more admin, events, etc.

We could include some things here, but I'd want to stick to repos that are software based projects though like the fishbase API - Though we could start a separate repo for roadmap for ropensci projects that aren't packages

---

A lot of the package level things discussed above are tedious to create manually (i.e. editing markdown pages or a wiki) with so many different repos, making programmatic methods more appealing. E.g., https://github.com/ropensci/roregistry/ has each package and some metadata - i update this manually. I've been meaning to get https://github.com/ropensci/roapi up on my ec2 server, which will allow us to use the data and all improvements to it on our website, etc. I'll try to get it up soon.

In addition, having all these bits of metadata in the roregistry at least, and in the ropensci API at best, will allow anyone to slice and dice to get exactly the info they're after:, e.g., what are the packages by each category (text mining vs. geospatial, etc.), which packages are on CRAN, which packages are in ropensci vs. ropenscilabs (indicating more stable vs. less stable) We could have preset toggles to answer these various questions as well

How one would consume this information is probably best as a website to replace ropensci.org/packages

If above sounds good, for this roadmap we could just concentrate on the higher level stuff,

• e.g, in each category (e.g., text mining, geospatial), what's the plan moving forward
• others higher level things?

I think https://github.com/ropensci/devroadmap#documentation is an import. higher level thing to talk about on the road map - indicating that it's an important piece of the puzzle

[cboettig]

Thanks @sckott ! I definitely agree that the roapi and something like the previous status.ropensci.org page would be very helpful in the wrangling.

It may also be necessary to have an annual or semi-annual exercise of just going through all repositories in rOpenSci, from top to bottom, probably as a team of us. This exercise could update tags in the api (status: beta / active / sunset, category) but also assess relative activity and development priority (relative to other repositories) for the next 6 mo or so. Maybe something like a repository-level set of milestones (packages x, y, & z will go to CRAN?) would help?

I think that projects like the documentation thing Scott mentions (e.g. automatically updating vignettes) also need to part of the prioritization discussion -- we have plenty of ideas/projects like that which aren't themselves R packages but could be super helpful.

[karthik]

I'm just getting a chance to read this road map. I agree that Carl has well articulated issues with this first draft.

Issues with this current version

• Following Jupyter's roadmap doesn't map one to one for us mostly because they are developing a single product and we have 300+ repos/projects that have no common thread (other than very loosely as facilitating access to data.)
• This is a little too much in the weeds (although this type of roadmap has a place elsewhere). Something like this could be useful for teams/maintainers/working groups to help stay on track for releases/plans for suites of packages (e.g. biodiversity suite and all their maintainers).

My vision for a roadmap

Step back significantly from the weeds (i.e. issues at a package level) and look at themes/areas we seek to advance. And then work towards creating a rough product map for each area.

For example, I'm sort of product managing the R documentation project at rOpenSci. This means, coordinating with Jeroen, Mika, the designer, and the front end engineer to come up with the specs, a rough timeline, and a tentative deadline to deploy. This could take up the next 2-3 months for these 4 (5 including me) to get this shipped. This effort includes various pieces like the UI/UX (designer and front end engineer), the R docs → html rendering (Jeroen), the shell scripts to go in Travis to deploy the examples, automatically rendering vignettes (Mika). The nitty gritty can be left out of the roadmap and to the team.

So you can imagine a Gantt chart that shows an expected date for an outcome, time commitments from people, and a way to determine when this are off the timeline.

The same could be done for other projects and themes (including maintenance or updates on existing packages). This will help determine if it is worth our time to add a few new features to a mature existing package (eg Taxize) OR leave that alone for a bit and work on something else. Hadley and others often say there will be no updates to packages for a little while (e.g. ggplot2, lubridate etc) to focus on other things.

This facilitates many other things: a) Ability of folks like Dan who don't have knowledge of specialized packages to get a sense of the what's coming up

b) Allows our community manager to share this with the public (people can know in advance that we will release x,y,z this year)

c) We can make decisions on when to switch gears, and when to get the whole team to sprint on particular projects that could be pushed over a hump. At present development is quite random.

[sckott]

@ropensci/leadership @jeroenooms @danielskatz

Thoughts on this new approach https://github.com/ropensci/devroadmap/tree/new#devroadmap (note it's branch new, not master) @karthik left a spot for the documentation project.

If we do start to work more on one or two major things at a time, then we could potentially list those in this document, with target dates, even if it's just a push on a single package - then when that's done, remove it, and replace with the next thing, etc.

[danielskatz]

This looks fairly useful. I guess one question is what other things the project is doing that might fall outside the devroadmap, and if there should be a highly-level planning document that tracks them too.

[sckott]

Right, the non-R package projects are important - and I imagine should be tracked separately - though we could rename this repo roadmap and include R packages as well as things that aren't just R packages like documentation work, or infrastructure projects