RFC: Community and Code Basics

[BlueReZZ]

Problem

We need to define some basic processes and conventions early so that engagement in the community and code is easier. We have learned a lot from helping people reuse software at eLife but also from our work with Hindawi, YLD, ThinSlices and the Coko Foundation on our other products. We propose the following as a starting point based on the output of a team session here at eLife. Feedback welcome.

Suggestion

Basics

• Libero is the name of the platform of applications, tools and services
• Individual components, applications, tools and services will have their own name that is descriptive and relevant to the solution they are providing
• The name Continuum is no longer in use
• Libero and some eLife specific applications power eLife's Journal
• Libero will be composed of parts of the existing system that powers eLife's Journal along with new components and changed versions of those existing components
• Libero is a suite of defined interfaces, libraries and applications. The applications are built from the set of Libero libraries, and can freely be replaced
• Use Github
• Use the libero Github organisation
• eLife are stewards of the code and community but changes are all collaborative

Decision Making

• Is done in the open, on github, using issues and pull requests as a way to make suggestions and discuss solutions before making a decision
• Larger decisions are done using a Request for Comments (RFC) process, using issues and a format similar to this RFC.
• The community will endeavour to meet at least four times per year

Code and Deployment

• MIT licensed by eLife Sciences Publications, Ltd as stewards of the community and code
• Primary languages are PHP for browser-facing applications and Python for the rest. JavaScript and SASS in the browser.
• Unit testing is required, TDD is preferred
• All libraries, components, applications, services and APIs should be versioned
• A "Container-first" approach to sharing and deployment
• Deployment and tools are platform agnostic (i.e. not only AWS)

High Level Feature Considerations

• Versioned content is required
• Previewable content is required
• Multiple content and front-end languages are going to be required
• Custom content is required
• Event reporting and auditing

Concerns

We are concerned that laying out these ideas now might seem like eLife want to dictate the direction of the product and community - this is not the case and hope that this RFC is taken in the spirit in which it is intended - to provide a useful starting point.

[BlueReZZ]

Updated "Docker-first" to read "Container-first" since we're trying to be agnostic - following a suggestion from @lsh-0

[Jenniferstrej]

Under "High Level Feature Considerations" I suggest we add: Event reporting (and potentially auditing)

[elrossco22]

The Digirati Team (Frank, John R, Stephen and Myself) discussed the above RFC and have the following questions:

• What does the versioning lifecycle look like
• Will there be per language coding standards enforced that cover linting etc
• Will there be generic ways of working that apply across all languages that covers best practices
• What does the current roadmap look like, is it already in existence or will this be produced during the initial 2 day meetup at the community sprint
• How will the project deal with contributions in particular the licensing aspects (CLA for example)
• How will disputes be settled, is there a voting system or similar for features etc
• How will a feature be decided as having a wide enough impact among adopters to be merged into the main line

[thewilkybarkid]

What does the versioning lifecycle look like

Everything will follow semver v2. (This won't be easy in places, eg the default design.) Stability should be favoured over features (ie we need to avoid breaking changes where possible, and when we have to avoid doing it too often). As for formal lifecycles (eg release schedules), not trying to guess upfront how that could work/whether it's going to be needed (since there's lots of individually-versioned parts; the applications themselves might benefit from one though).

Will there be per language coding standards enforced that cover linting etc Will there be generic ways of working that apply across all languages that covers best practices

Yes, not from day 1 but before '1.0'. (We want to enforce coding standards in CI etc, but that's something we'll start to do over the next few months.)

What does the current roadmap look like, is it already in existence or will this be produced during the initial 2 day meetup at the community sprint

We'll go through it at the start of the sprint (too much detail for an RFC).

How will the project deal with contributions in particular the licensing aspects (CLA for example)

Ping @BlueReZZ.

How will disputes be settled, is there a voting system or similar for features etc How will a feature be decided as having a wide enough impact among adopters to be merged into the main line

As stewards, eLife will have the final decision. This may change as the project grows of course.

Ideally RFCs (like this) will be used to propose new features (as they probably impact more than one service). The community can then have their say.

[BlueReZZ]

How will the project deal with contributions in particular the licensing aspects (CLA for example)

This is under discussion as we're doing more research into it currently. It is also something we can talk about more in the workshop. eLife want to be as open as possible but understand that a fully permissive licence like MIT, which we usually use, is difficult to dual-licence for aiding in the sustainability of the software community. There are a number of options that permit this under an open licence though, through trademark licencing and licencing the core software differently to certain contributions.

Changing the licence is difficult under an "in equals out" contributor agreement as we'll have multiple intellectual property owners but may be viable given the limited number of contributors at this stage. Going forward though a CLA based on existing, popular and well understood agreements would be useful. Advice is available on contributorsagreement.org and from OSS Watch.

I'll add a discussion on this topic to Monday's agenda as having this agreed early is beneficial.

[BlueReZZ]

Following the Libero Community Sprint and subsequent work with the community there has been significant progress on these basics, that are now recorded in the governance model, code or that have been superceded by another RFC. This issue can be closed with further information specifically at:

• Deployment tools have been discussed in an RFC on Continuous Delivery https://github.com/libero/community/issues/13
• Governance models have been decided and will be available soon, but a summary can be found in a blog post on eLife
• The CLA is now agreed and ready at https://libero.pub/governance/cla/
• The primary language choices still stand but a concentration on PHP until the first MVP has been discussed in https://github.com/libero/community/issues/14