As the title I was wondering if it was time to rebrand the forum and organisation away from the overlap with the epinowcast package or alternatively rename the package (though my preference is the former vs the latter). As part of this we would also go over the text surrounding the community to make sure it aligns with where people are and make a new logo.
My reasoning as to why this might be a good idea is that the scope of the forum and seminar series has really widened to be less tool focussed and to more broadly be across situational awareness for infectious disease. Similarly we now have a range of packages in the epinowcast GitHub organisation that aren’t directly related to the originally epinowcast package. Over time as we formalise onboarding I only see this growing.
I see the current name and framing as being confusing given this and holding a widening of the community back.
We also have related efforts in Julia under the epiaware banner that I see as a good fit to the work being done here and it seems a shame to silo based on programming language.
What do people think and what is the path forward? Discussion here, then an open call, followed by a poll could work?
In terms of other names and branding the general situational awareness framing appeals to me. I also like the epiaware name but that just invites the same issue down the line when the nascent Julia ecosystem gets off the ground.
Part of the motivation for this is I am trying to work out how we can support software maintenance as the current approach is not working (at least for me zero grant success). I’ve always seen the future as being non centralised and “ownerless” so very keen to take steps like this to make it happen. @sbfnk and are are currently writing an application for the SSI (Research Software Maintenance Fund | Software Sustainability Institute) to try and get some funds to think about merging some of the epinowcast and epiforecasts efforts and to build more serious governance and prototype onboarding methods (draft coming to GitHub soon will look here) so steps like this fit there as well.
5 Likes
Good idea @samabbott.
I agree it’s confusing for the [forum, community, organisation] to be called epinowcast.
I’d probably favour a path forward based on determining the function that the [forum, community, organisation] are intended to provide, and then choosing a name on that basis.
I’d be in favour of names which sound more like organisations than like software packages. For example, I think epiaware sounds like a software package (and I agree on having the same issue down the line). An example of a name which sounds like an organisation is “Software Sustainability Institute”.
My perspective on the distinguishing feature of this community is a focus on open source tooling for epidemic response. That would push me to like names which reference “open” or “open source”.
Rogue suggestion: the Epiverse is a project which appears to be close to the goals of the epinowcast community. Have we considered merging epinowcast projects into the Epiverse? This could provide a solution on software maintenace.
2 Likes
Sounds very sensible as a way forward - I’d agree with the name change of the organisation/community being preferred to the package.
1 Like
I also agree that changing the name of the organisation is a good one.
I think the first step to trying to determine the rebranding is determine the goals of the community more generally. From this, an appropriate name for the community may arise.
As for how, it could be a multi-step process. Perhaps a poll is useful first to try to determine what community members see as the purpose/goals/vision of the community is. Then, have an open call to discuss more specific language and discuss specifics using the poll results as a basis.
3 Likes
I agree with the general intention and separating the org from the package name. Thanks @samabbott for putting this to the community.
I also agree with all of the suggestions made and like @kylieainslie’s outline of a process.
Have we considered merging epinowcast projects into the Epiverse? This could provide a solution on software maintenace.
I’m not sure it does – as Epiverse-TRACE is ending its period of initial funding it is currently in a bit of a transition phase, and the problem of software sustainability and maintenance is very acute in this context. That said I think it’s worth considering where there are touching points or overlaps that would lend themselves to joint efforts of mutual benefit.
I agree with @kylieainslie and others.