H5P Guides

Contribute code (Pull requests) to existing H5P libraries

Thank you for considering to help improve existing H5P content types. In this guide you'll learn the recommended ways for you to efficiently improve H5P content types, by creating pull requests. By following this procedure, your pull request will be reviewed and merged in much quicker, and the chance of it being refused will be much lower.

A pull request is like a super valuable feature request. It is a feature request that contains a suggested solution. However it comes with the potential of not being accepted for one of two reasons:

  1. The maintainers of the code doesn't find the new feature useful enough. They might think that most people won't use it and it will complicate the code and the user interface.
  2. The maintainers don't like the suggested solution. I.e. they don't like the code in the pull request.

The H5P Core Team try to avoid that community members spend time working on code that doesn't gets accepted. To do this the Core Team urge community members to prequalify their pull requests by doing the following:

  1. First raise an issue on GitHub explaining what feature you want to add. Make sure you explain why the feature is needed and how you want to add it both technically, UX wise and accessibility wise. See the example below.
  2. A maintainer will reply to your issue. You might get a green light for your pull request. You might get suggestions on how you can make an even better pull request. You might also get a message that the feature won't be accepted, so you don't need to make a pull request.
  3. When you get a green light for the pull request it also comes with a promise that the maintainers will prioritize reviewing and merging in your pull request quickly.

Example issue

Let's say you want to make Interactive Video become able to show/hide interactions every tenth of a second instead of just every second. Your issue could look like this:

I want to prequalify a pull request related to the following:

User story:

As an author I want to be able to specify the times for when interactions appear and disappear with greater precision so that I can sync them better with events in the video.

With today's functionality I often find that I have to compromise and either show the interaction a bit too late or a bit too early.

UX:
Description and placeholder texts related to start and stop points for interactions will be updated to reflect that they allow tents of seconds precision.

Accessibility:
Not relevant

Technical solution:
I plan to rewrite the toggle interactions logic so that it will have a list of the next hide/show events ordered so that the next event comes first given that the user doesn't skip in the video, only plays and pauses. For every tenth of a second the list will be inspected to see if the time for the next event has passed. It will also detect if the user has skipped in the video by comparing the video time with the previous video time.

If the user somehow skips in the video the current brute force methodology will be used to toggle visibility of items, and the list of the next events for normal play/pause movement will be updated given that the user isn't currently actively seeking in the video.