On 2/2/2018 5:41 AM, Simon Lundström wrote:

Thank you for your feedback!

> I like mailinglists and IRC but the most important for me is that the 
> questions are answered, be it by employees or the community

I completely agree with this. Seeing how spread out the current
community is between the various platforms was what inspired this topic.

> ... and that 
> the aim is to leave no questions unanswered. 

Also important, but this will definitely require an infusion into the
user base of people willing to invest the time. It may also require
going where the user or "customer" is and meeting them there. An ideal
situation is to provide a solid service offering that attracts satisfied
users enough to hang around and offer the same service back to others.

> IM (such as IRC) is not 
> well suited for replies which might take days but rather for quick 
> yes/no questions.

Agreed, but I'd also say that questions with a little more depth could
be handled as well, with some replies from mods pointing the requestor
back to documentation for more thorough answers.

> Since the answerers are in minority I'm OK with whatever way they are 
> comfortable with answering questions.

I hear you.

> To get fewer questions asked (over and over again) having someone which 
> compiles the most often asked areas/questions and documents them where 
> it's relevant. 

There is an existing section in the docs, but it's currently more of a
placeholder than anything else right now:


It could definitely use some work.

> Since this often requires some sort of access it might be 
> suitable to be done by an employee.

The great thing is, the documentation is housed in a Git repo and Pull
Requests are happily accepted by anyone, not just employees. I am not an
employee, just a member of the community that is trying to learn as much
as I can about rsyslog. I decided that the best way for me to do this is
to assist with documentation enhancement tasks as I can work them in.
This includes everything from minor typos, rewording or refreshing
content all the way up to the creation of new guides (which I've yet to
do, but hope to do so in the future).

When you get down to it, any contribution is appreciated, even if it's
just taking the time to report problems that you find with the docs that
someone else might have missed.

Please see this section of the rsyslog-docs README for more info:

Slight tangent:

As I've become more familiar with the project, I've heard many times the
request for updating and expanding the guides section of the docs. I
expect that there is strong demand for smaller guides in order to get
users started with configurations that they may not be familiar with.
Out of the box, local logging is enabled and working with light
filtering applied based on facility and priority. This starter
configuration usually includes a starter example of forwarding from a
client to a remote receiver, but the example is very rudimentary. I
think we could use some content that bridges between that point and the
more complete, "How to send your logs to Elasticsearch" guides.

For anyone wishing to get more involved with rsyslog, I believe this is
a great way to do so while helping others.
rsyslog mailing list
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of 
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE 

Reply via email to