Promregator is continuously growing. Besides implementation topics like bugs and (feature) enhancements (to which any developer is welcome to contribute anyway :grin:), Promregator has come to the age where additional support is appreciated. Especially in the following topics, we currently seek support from volunteers:

Community

The community is still in its infancy. There are many open topics, which would be great to be tackled. Amongst them are:

• Seek and find an environment where a user-level discussion/mailinglist/forum may be hosted. This could be anything from Discord, Google Groups or a public forum. In general, I currently dislike a little the idea to make the "big Internet players even bigger" by feeding them with additional data. However, you may convince me...
• Check if that very same infrastructure could also be used for developer's internal discussion. As of today the number of regular code contributors is small (not to say, it's one), but hopefully this also changes in the near future.
• Check if that very same infrastructure would also support something like a "Promregator announcement" list to which all users could subscribe to. Writing information to that channel would be highly restrictive, e.g. if new release were sent or in case severe issues (e.g. security-related stuff) would have to be communicated. There shall not be any discussion permitted on that communication channel.
• Moderate the user-level discussion forum/mailinglist accordingly.
• Provide assistance for first-time users, guiding them after their first hurdles especially once they have finished the quickstart guide.
• Promote (but don't sell!) Promregator to others. This could mean (but is not meant to be limited to)
  • Recommend it to cases you find on other forums/mailinglists/...
  • Give a talk on a conference on what you did using Promregator
  • Record videos (for Youtube and a-like) describing how you get started with Promregator and/or special topics.

Documentation / Knowledge Management

We have a huge bulk of documentation in the meantime. The author of almost all the stuff wasn't a native speaker. It is more than likely that there is a larger number of spelling mistakes and issues with grammar out there. Therefore, a native speaker could help by

• Proof-reading the documentation (simply from a point of view of language). Send Pull Requests to fix the stuff
• Improve the documentation as whole, by adding additional tutorials, quickstart guides, FAQs, etc.
• Our current documentation is purely written in Markdown. Whilst this is not bad as such, there are much better content management systems and users today are used to look at much better designed webpages. We could make use of ghpages or even consider porting all our documentation to an own domain. A concept for that would be needed and shall be discussed.

Testers

Many cases are today already covered by appropriate unit tests in Promregator (and they already provide a lot of test coverage!). Unfortunately, some of the more complex environments, where Promregator is supposed to run, are not covered by test automation yet. This means at least two things where additional support is appreciated:

• At least on every minor release (not just a patch), there is need to perform manual tests (at least until the stuff is automated). We should have short tests scripts for those cases and the stuff should be tested for regressions.
• Better than manual tests would be to automate those stuff. The concept of MIT/integration tests is currently still open. Thus, there is huge room for influence on this topic.

Performance Analysis

One major quality Promregator has to provide is performance: As scraping intervals usually are in the range of 10 - 15 seconds, responses need to be generated for targets involved within that same time frame. So far, performance is only ensured using timeout parameters, but we lack detailed performance analysis. This brings up the following tasks, where a contributor could help:

• Provide a proper concept where and what shall be subject to performance measurements.
• Implement a performance measurement environment into the Jenkins' delivery pipeline, such that performance measurement takes place automatically.
• Store the results somewhere centrally, providing a historical overview such that performance comparison over time becomes possible.

New Environments

Promregator is delivered using several channels. This permits to use it in various known and unknown environments. Mainly lacking knowledge about many of them, we did not run them before in environments such as

• OpenShift (see also issue #101)
• Kubernetes
• there are for sure more of them...

If you have experience in such a topic, test-drive Promregator there. You then may contribute a How-To document (best: use a Pull Request for that, putting it into the "docs" folder). Also your experience during support then will be helpful, as you may respond to inquiries coming in for detailed information / special cases via Github issues.

How to Get Involved

If you are interested in taking over (or participating in) one of these topics mentioned above, or if you are seeing further fields of improvements where you would like to contribute to Promregator, please drop an email to github at schmoigl-online.de. This is especially to take care that nobody is doing unnecessary double-work or that two people are working on the same topic, but they don't know of each other!