<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><span style="white-space: pre-wrap">> </span><span
      style="white-space: pre-wrap">I would </span><span
      style="white-space: pre-wrap">strongly encourage candidates to reply to this email with a [brief]
</span><span style="white-space: pre-wrap">> campaign: who are you, what work have you done for the community, why do
</span><span style="white-space: pre-wrap">> you want to be on the TOF, etc.
</span></p>
    <p data-start="74" data-end="77">Hi,</p>
    <p data-start="79" data-end="180">my name is Alexander Hansen
      (GitHub: pointbazaar), firmware engineer at 9elements working on
      OpenBMC.</p>
    <p data-start="182" data-end="365">I have contributed to sdbusplus,
      bmcweb, entity-manager, dbus-sensors, and libpldm, working on
      D-Bus modeling, <br>
      Redfish multi-host support, and platform support (e.g. Tyan
      s5549/s8030 platforms).</p>
    <p>Some concrete examples of my work:<br>
      <br>
      - bmcweb: binary size optimization with busybox approach (one
      binary for both the daemon and cli utilitiy)<br>
      - dbus-sensors: modernize debug logging with lg2<br>
      - phosphor-bmc-code-mgmt: parts of the common code implementation
      underpinning many device specific code updaters<br>
      - entity-manager: design and implementation for reworked physical
      topology  (Type: "Port" configuration records)<br>
      - sdbusplus: discussions and patches around <code
        data-start="446" data-end="459">object_path</code> behavior and
      API design (default values, usability, and correctness)<br>
      - libpldm:  libpldm++ library implementation<br>
      - phosphor-led-manager:  removal of the yaml config mechanism in
      favor of json based configuration ('one way' to do things)<br>
      - removal of preprocessor based conditional compilation in favor
      of `if constexpr` in various repos<br>
      <br>
      > <span style="white-space: pre-wrap">why do</span><span
      style="white-space: pre-wrap"> you want to be on the TOF

I believe OpenBMC could benefit from some controversial ideas like

- deletion of unused features. (unused code should not block upstream development, i do not count private downstream forks)
- consistency of implementation across repositories (contributors should not have to adopt an entirely new style for every repo)
</span><span style="white-space: pre-wrap">- reducing the amount of code duplication</span><br>
      <span style="white-space: pre-wrap">- 'one way' to do things instead of various (possibly incompatible) alternatives
- progress on the upstream community code over stability for downstream forks

If you like these ideas then i can represent them for you as part of ToF :)</span></p>
    <p><span style="white-space: pre-wrap">
</span></p>
    <div class="moz-cite-prefix">On 3/18/26 21:11, Patrick Williams
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:absG_8pQilMHGMnO@heinlein">
      <pre wrap="" class="moz-quote-pre">Greetings,

For the TOF elections for this half, we had 7 qualified individuals
nominated and there are 4 seats expiring.  Therefore, we are going to
have to hold an election for the half. 

The 7 nominated developers[1] are (alphabetical by Github IDs):
    * Andrew Jeffery
    * Brad Bishop
    * Deepak Kodihalli
    * Jagpal Gill
    * Jayanth Othayoth
    * Alexander Hansen
    * Patrick Williams

A few key points about the election:
    - Voting is by Ranked Choice Voting.  The order you give as your
      preference matters [2,3].

    - TOF members represent the development community and not their
      companies.

    - Since there are 4 seats up for election, you may submit a vote
      with up to 4 candidates.

With this being the most nominated-for election in TOF history, I would
strongly encourage candidates to reply to this email with a [brief]
campaign: who are you, what work have you done for the community, why do
you want to be on the TOF, etc.

Votes will be accepted until April 1st, 2026 at 12:00 GMT from qualified
votes[4].

As with the last election, we have a tool to facilitate voting[5].  You are
expected to fork the Github repository, run the tool, commit the
resulting JSON file, and create a Pull-Request to submit your vote.

If you have the `gh` tool this would be as follows:
```
gh repo fork --clone openbmc/tof-election
cd tof-election
./vote --user <github-id>
# make your selections with 'vote N', 'save', 'quit'
git add 2026H1/votes/<github-id>.json
git commit -s -m "2026H1: <github-id>: add vote"
git push origin
gh pr create
```

[1]: <a class="moz-txt-link-freetext" href="https://github.com/openbmc/tof-election/blob/main/2026H1/candidates.json">https://github.com/openbmc/tof-election/blob/main/2026H1/candidates.json</a>
[2]: <a class="moz-txt-link-freetext" href="https://github.com/openbmc/docs/blob/master/tof/membership-and-voting.md#terms-and-elections">https://github.com/openbmc/docs/blob/master/tof/membership-and-voting.md#terms-and-elections</a>
[3]: <a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Instant-runoff_voting">https://en.wikipedia.org/wiki/Instant-runoff_voting</a>
[4]: <a class="moz-txt-link-freetext" href="https://github.com/openbmc/tof-election/blob/main/2026H1/rollcall.json">https://github.com/openbmc/tof-election/blob/main/2026H1/rollcall.json</a>
[5]: <a class="moz-txt-link-freetext" href="https://github.com/openbmc/tof-election">https://github.com/openbmc/tof-election</a>

</pre>
    </blockquote>
  </body>
</html>