Project Resources¶

• Source code:https://opendev.org/openstack/horizon

• Documentation:https://docs.openstack.org/horizon/latest/

• Project page:https://launchpad.net/horizon

• Bug tracker:launchpad:horizon

• Code review:https://review.opendev.org/#/q/project:openstack/horizon+status:open

Communication¶

• IRC channel:#openstack-horizon at OFTC

  Most active contributors are online at IRC while they are active,so it would be the easiest way to contact the team directly.Note that all IRC conversations are storedhere.

• Mailing list:openstack-discusswith[horizon] tag.

  The mailing list would be a good place if you would like to discuss yourtopic with the OpenStack community more broadly. Most OpenStack users,operators and developers subscribe it and you can get useful feedbacksfrom various perspectives.

• Team meeting:

  The horizon team has a weekly meeting which covers all things related tothe horizon project like announcements, project priorities, community goals,bugs and so on.

  There is the “On Demand Agenda” section at the end of the meeting, whereanyone can add a topic to discuss with the team. It is suggested to addsuch topic to the On-Demand agenda in the “Weekly meeting” inhorizon release priority etherpad.

  • Time:http://eavesdrop.openstack.org/#Horizon_Team_Meeting

  • Agenda:https://wiki.openstack.org/wiki/Meetings/Horizon

Contacting the Core Team¶

The list of the current core reviewers is found atgerrit.

Most core reviewers are online in the IRC channel andyou can contact them there.

New Feature Planning¶

If you would like to add a new feature to horizon, file a blueprinttohttps://blueprints.launchpad.net/horizon. You can find a template for ablueprint athttps://blueprints.launchpad.net/horizon/+spec/template.The template is not a strict requirement but it would be nice to covera motivation and an approach of your blueprint. From the nature of GUI,a discussion on UI design during a patch review could be more productive,so there is no need to explain the detail of UI design in your blueprintproposal.

We don’t have a specific deadline during a development cycle. You can propose afeature any time. Only thing you keep in your mind is that we do not mergefeatures during the feature freeze period after the milestone 3 in each cycle.

There are a number of unsupported OpenStack features in horizon.Implementing such would be appreciated even if it is small.

Task Tracking¶

We track our tasks inlaunchpad:horizon.

If you’re looking for some smaller, please look through the list of bugsand find what you think you can work on. If you are not sure the status ofa bug feel free to ask to the horizon team. We can help you.Note that we recently do not maintain ‘low-hanging-fruit’ tag and some ofthem with this tag are not simple enough.

Reporting a Bug¶

You found an issue and want to make sure we are aware of it?You can do so onlaunchpad:horizon.

Please file a bug first even if you already have a fix for it.If you can reproduce the bug reliably and identify its causethen it’s usually safe to start working on it.However, getting independent confirmation (and verifying that it’s not aduplicate) is always a good idea if you can be patient.

Getting Your Patch Merged¶

All changes proposed to horizon require two +2 votes from the horizon corereviewers before one of the core reviewers can approve a change by giving“Workflow +1” vote.

In general, all changes should be proposed along with at least unit testcoverage (python or JavaScript). Integration test support would beappreciated.

More detailed guidelines for reviewers of patches are available atOpenDev Developer’s Guide.

Project Team Lead Duties¶

All common PTL duties are enumerated in thePTL guide.

The horizon PTL is expected to coordinate and encourage the core reviewer teamand contributors for the success. The expectations for the core reviewer teamis documented atCore Reviewer Team and the PTL would play animportant role in this.

Etiquette¶

The community’s guidelines for etiquette are fairly simple:

• Treat everyone respectfully and professionally.

• If a bug is “in progress” in the bug tracker, don’t start working on itwithout contacting the author. Try on IRC, or via the launchpad emailcontact link. If you don’t get a response after a reasonable time, then goahead. Checking first avoids duplicate work and makes sure nobody’s toesget stepped on.

• If a blueprint is assigned, even if it hasn’t been started, be sure youcontact the assignee before taking it on. These larger issues often have ahistory of discussion or specific implementation details that the assigneemay be aware of that you are not.

• Please don’t re-open tickets closed by a core developer. If you disagree withthe decision on the ticket, the appropriate solution is to take it up onIRC or the mailing list.

• Give credit where credit is due; if someone helps you substantially witha piece of code, it’s polite (though not required) to thank them in yourcommit message.