Team UX Roadmap (June to December)


Yes, I have mockups! They are a little dated at this point and need to be updated. Specifically after meeting with Timo, he had an excellent suggestion of adding a “quantity” of hosts mechanism. Give me a little bit to grab those mockups and have them in a place I can share here. Thanks!


After discussions with the larger team a few items have shifted in priority. Namely the SCSS work is now the lowest priority item on our list. Here’s an updated roadmap:

  1. Create a way to extend components in react (slot/fill)
  2. Downstream login page branding (6.7)
  3. Stabilize the build/release process
  4. Support react development in plugins
    • Using small packages we can share with core and plugins.
      Redesigning the javascript stack
    • Moving infra related code to shared packages
    • Creating/stabilizing needed infrastructure
    • @theforeman/vendor
    • @theforeman/env
    • @theforeman/builder
    • @theforeman/core
      • Components
      • I18n
      • Router
      • slot-and-fill
      • Tour
      • Forms
      • Networking
      • State
      • Legacy Bridge
      • Modals infra
  5. Simple host wizard
    • Create/provision host based on subset of options (i.e. the happy path)
    • “Expert mode”= old form
  6. Bring SCSS into webpack
    • Research how exactly to do this
    • @theforeman/vendor - will provide the base scss 3rd party libs with their variables and mixins.
    • @theforeman/builder - will provide the building tools so core and plugins can build their scss files to css files.
    • Katello/bastion scss

Thanks @Walden, is there a timeline or date when we can expect these things to be done? I’m specifically interested in point 1. and 3. which are blockers for some plugin work (ansible variables overrides in host form, new UI in templates plugin from top of my head).

what would be the best way to keep folks aware of progress? I’m very interested to know where do we stand regarding #3 - can you at least tell us where do we track things? ATM it feels like a big black box?

Our scrums are open to anyone who wants to come to them and we are currently trying out asana as a project management tool. If anyone is interested in being added to our project please let me know and I’ll be happy to add you.

I don’t see how our processes and tracking are any more of a “black box” than any of the other teams who work on foreman. In fact, we have had community members say that we’re the most transparent of the teams.

Those two items are the top items on our list (as the login page branding is basically done pending reviews).

Here’s a link to our gantt chart that shows the state of our roadmap.

Obviously this is software development and these dates are subject to change but these are the dates we’re working with as our goal for these items.

can you describe where item #3 is being tracked? (e.g. which pull requests I should follow?) is there a tracker redmine issues for pending items etc?

1 Like

Thanks @walden, that answers my question. Seems we’re very close, which is great.

The reason the @ui_ux team is getting these questions is, this became a critical path for many other efforts. As stated here 2 weeks ago, item #3 is blocking 1.23 release. Yesterday, a heads up 1 month before branching was published. Originally this was expected by 1.22 timeframe. There are features that are blocked on this, e.g. templates ui since February. Tasks, REX, Ansible and Katello plugins rely on current solution, which stability was desribed as experimental by @ui_ux team here. The last thread I’m aware of for this effort is not updated since end of March and there are questions without answers. The linked PR was pushed to 8 days ago, without any comment, last update is there are some test issues which is information more than 2 weeks old.

It’s great you’re sharing the roadmap, please continue and bear with us. I’m sorry if that feels as overcommunication, but I hope the whole team now understands the importance and what information we’re searching for.

1 Like

Everything is being tracked in asana, I sent you an invite.

@sharvit do you mind providing an update to the thread mentioned above?

It doesn’t feel like overcommunication, I think this is the right amount of communication abd I think that all of the information on what we are working on is there if people want to get it.


This is a list of things that should be done (just the asana list exported as pdf):

This is actually still the status, there are some tests need to be fixed.
I could fix the js related issues in jest and I will probably update the PR today.
Then I will jump to the ruby integration-testing to check what went wrong.

a suggestion - we can generate a weekly report from asana and publish it here
I played a little bit with weekdone, and it looks nice !

I don’t think it’s my place to comment on roadmaps from another organisation, but I believe if items #1 and #3 are done, there is no immediate need for any further tracking. From my (community) perspective, you’re trying to be more transparent and communicate a lot, but don’t get the items done. Don’t get me wrong, this is not supposed to mean the UI team is playing minesweeper all day. I just want to say, that the roadmaps of the UI team are pretty clear to me. (I can’t say that about other teams fwiw.) I’m just saying that we need all hands on deck to fix items #1 and #3 and not have more tracking.

1 Like

From a Foreman release perspective I do miss the Redmine issues. I don’t need exact tracking of the progress, but I would like to easily find all related PRs. Given we declared the packaging situation as blocking for 1.23, it is odd that there’s no Redmine issue.

Note that I’m not saying that you need to use Redmine for all tracking (plenty of teams use their own internal scrum/kanban boards which refer to other issues)

Created a follow-up discussion about the Host Wizard: Host Wizard Kickoff


We are currently in the development process of a new server and application deployment approach for Foreman.

Normally servers aren’t deployed for their own sake, but to serve as platform for applications.

Thus we believe, that server deployment should be application centric and self service based.

The use case scenario would be:


  • Creates an application definition including servers and an application orchestration mechanism (ansible playbook, salt state)
  • Defines variables that need/can be changed by the Application owner

Application owner:

  • Creates new application instance from application definition
  • defines needed variables
  • deploys application including servers (one click deployment)

The current development state is in a very early state and allows the definition on a one server deployment and a basic self service portal.

We’d be very happy if you’d take a look at the plugin and we’re happy about any type of feedback :slight_smile:

Foreman Application Centric Deployment

Thanks, Mark

1 Like

Thank you for sharing @hlawatschek :+1:

I looked at the javascript code and I can say I like the code quality +1

Some suggestions to improve the code quality:

  1. Create smaller and reusable React components.
    The ParameterSelection is one big component that handles many tasks and can turn to many smaller pieces combined together by the ParameterSelection component.
    A good starting point would be to create a standalone component for each renderSomething methods.

  2. I would suggest using travis to run tests on the cloud and install coveralls to track test coverage.

As for the roadmap, I would suggest paying attention to:

  1. @MariaAga and @Ron_Lavi work in progress on “API calls as a middleware” that can dramatically change (for good :slight_smile:) your redux actions and reducers.

  2. @amirfefer work on client-side navigation that will allow your plugin pages to load faster.

  3. The UI teamwork in progress around @theforeman/env package that will bring your plugin a development enviorments and tools so you can use the latest javascript syntax, run tests using jest, run storybook to demo your components, and running linting tools to verify code quality and consistency.

Thanks again for sharing, we will update once those features are ready for a demo.


Thanks @sharvit for you comment and your help. I added travis tests and tried to move some code from ParameterSelection to sub-components.

I’m very interested in react-router / client-side navigation. Hope this can be used for plugins, too.

This is the plan, see @amirfefer PR-6936 and more specifically, the docs about plugins which includes there:

You are welcome to add your comments if you have any, afaik @amirfefer will boost the effort soon.