Hi OpenEMS Community! Welcome & Introduction

[siddhiphal]

Hi OpenEMS Community!

I’m Siddhi, M.Sc. Project Management student at GISMA University, Berlin.

Background: 2.75 years managing operations at scale ($1M+ programs), currently researching AI-driven battery storage optimization and grid coordination systems. EU citizen based in Berlin.

I’m joining OpenEMS as a community coordinator to help scale the contributor experience. I can help with:

✓ Discussion organization & templates
✓ Bug report triage system
✓ Contributor onboarding guide
✓ Community workflow optimization
✓ Forum structure & navigation

Goal: Reduce friction for new contributors, organize discussions, help route technical questions efficiently.

Excited to contribute to infrastructure that powers the energy transition!

How can I help?

[sjjh]

Hi @siddhiphal, great to have you on board!
Looking forward to your support and contribution to this community. I’m just another (end) user, making small documentation contributions once in a while and trying to get our system up and running (which involves getting additional components added).

@siddhiphal

How can I help?

Personally I would suggest looking at following aspects (in no particular order), but there are probably more experienced people than me around:

• “eat your own dog food”, imagine being e.g., a interested house owner. Set up OpenEMS yourself for the first time. Maye your first contribution to the repository. What did you struggle with? How can you support to ease it?
• change the setting to allow registered users (of a certain trust level) to open up new topics without manual approval by a third party
• create a Wikipedia article (needing some sources) for OpenEMS
• create a possibility (e.g., merge week?) for the core devs to bring open pull requests down to a small one digit number
  • set-up a process so that open pull requests stay a one digit number
• triage open issues/bugs, bring the number down, exclude relevant issues from the stall-bot, prioritize relevant issues, feed them into the developer pipeline (not sure how close collaboration with Fenecon is in this regard)
  • ensure, that new bug reports have a good quality, such that devs can easily work on them
• change procedure of back-porting Fenecon changes to upstream