[DISCUSS] mspec a show-stopper? Was: AW: Reflecting on how we volunteer to do stuff

[Christofer Dutz <ch...@c-ware.de>]

Hi Lukasz,

do you really think mspec is a "show stopper"? ... cause I thought of it more as a "game changer" and an "enabler".
Cause let's face it: writing drivers for protocols is not a simple task. With mspec I think we have reached a simplicity that I haven't seen anywhere before in this sector. And I think seeing that some of our new contributors could just checkout and learn from the exising examples and produce their own mspecs in a short amount of time, proves that it's actually a pretty powerful tool.

I think the protocols you were working on we simply just a nightmare to start with ... no tool will help you with such a task and make the bad dreams go away. Perhaps if you wrote the dirvers manually you would have been quicker in case of CAN.

 I agree that we could need a beginners guide, but currently just don't have the time to write one. I did submit talks and workshops to multiple CFPs now and I hope that from this I'll be able to prepare some content that we can use or even that some recordings might come out of it, which we can link.

And regarding your complaint about using Maven excessively: I agree in the beginning I tried to mavenize the non-java parts, but if you actually had a look recently, that had changed more than a year ago. 

Right now every non java part uses the build system native to that language:
- PLC4C uses CMake
- PLC4CPP usses CMake
- PLC4Py (the initial version) uses the Python build system
- PLC4Go uses go
- In my feature/PLC4Net branch you can use the default .Net build system to build

Even the default directory stuctures were mostly used.

You can even develop in PLC4Go, PLC4C, PLC4C++ by just opeining your IDE of choice in that particular Language. So I don't quite get the point of your complaint.

Yes: in order to generate a new driver in any of these languages, you also need to setup maven in order to generate the code. I even reduced the problems here by checking in the generated code for C and Go. So you really only need to run the maven build to generate, if the mspecs change or you want to add a new driver. The other reason for the Maven integration is simply to have the builds run in Jenkins. Of course we could not do that and setup a Zoo of jobs, each building part of the project, but as I'm currently the only one actually taking care of these plumbing tasks, I'didn't want to do that (And I could see for other projects how bad this actually works)

You could probably change the requirement to run the maven code-generation, but for that you would need to implement the code-generation for those languages/build-systems. Feel free to do so, if this is an itch you feel needs scratching.

What do you others think about this?

Chris






-----Ursprüngliche Nachricht-----
Von: Łukasz Dywicki <lu...@code-house.org> 
Gesendet: Freitag, 8. Januar 2021 00:23
An: dev@plc4x.apache.org
Betreff: Re: Reflecting on how we volunteer to do stuff

Its low part of the season. People got locked down in their homes (Poland just entered new year with another lockdown, Germany is same AFAIK), so I am not yet worried by "slowdown" you observe.

I am prime example of someone who has more will that abilities to contribute. You know I stayed around since long time and eventually made few contributions. I think there might be few more like me. I agree with you that making an open community (I think we are) and opportunity to contribute is necessary to give dopamine shots we all need.

Now - in terms of low hanging fruits. I saw very few successful initiatives such this. Main reason why they fail is .. well, people are not often not even aware of them. Making them listed somewhere in JIRA does not help (how often do you look in github 'need helps' issues?).
Its mainly about making entry point easier for people who use project.
I know how much effort it was for you to help with Ethernet/IP. You personally helped me with almost every mspec related contribution I made so far. I believe that our main "show stopper" is the mspec. Even existing project staff don't know how to start with it or have troubles with it. If we could publish beginner guide to mspec that could turn into more people trying to write their protocols.

Also we use heavily Maven. While it simplifies life for us (java folks) it makes problems for everyone else. I recall Bjorn complaining about it for C(#/++?) stuff. Not all people know how to use it, especially if they are not from old Java landscape.
Our docs are dug under maven folders making it hard to contribute docs.
Maybe pulling it up could help.

This are just my free thoughts on how to make it easier.

Cheers,
Łukasz

On 07.01.2021 10:28, Christofer Dutz wrote:
> Hi folks,
> 
> I'd like to discuss something ... something I have been noticining in the last year or so.
> 
> We're a cool bunch of people, doing awesome stuff. However momentum in the project has sort of slowed down quite a bit. I know we have some great new initiatives going on, but let's say it's become a bit quiet around the folks which have been involved for a longer time period.
> 
> I would like to get more people involved and active in the project. Therefore I would like to strart posting low-hanging fruit here on the list.
> 
> In the past when I did so, the community was quite fast in raising hands and volunteering to do things. However volunteering is one thing, actually doing seems to be something else. In my impression we could improve on the delivering side. I know we are a volunteer driven community and you are therefore contributing voluntarily in your free time or in the time your company is paying you. But ... keep in mind:
> 
> 
>   *   If you volunteer to do something, probably others will not raise a hand to also contribute. If you now don't deliver what you signed up for, the others won't either.
>   *   If you volunteer to do something, I will think that this base is covered and not jump in (I don't want to interfere in every initiative, but I am happy and willing to help if help is needed)
> 
> So could you please do me a favour?
> 
> If I start posting some low-hanging fruit in the near future, please consider if you will also have the time to actually do so, before signing up?
> 
> Chris
> 

AW: [DISCUSS] mspec a show-stopper? Was: AW: Reflecting on how we volunteer to do stuff

[Christofer Dutz <ch...@c-ware.de>]

Hi,

thanks for your input on this.

The thing is, we could do with the website content what we want ... we could even maintain it in a dedicated repository, use whatever fancy web-framework we want. 

The main reasoning for this setup was simplicity. 

Of course you need to know that you need to edit content in "src/main/site" and you gotta use Asciidoc (even if you could use html, md, you name it) ... but in all other cases you need to also learn how to build/deploy/edit the page. For all other projects I work with, the website is always the one receiving the least love and it's also the one I feel most uncomfortable with updating, as I don't want to have to learn how to do it first.

So in the end: If you wanna do something, you gotta learn how to do it. 

With our approach you also need to learn something, but I think the amount of things you have to learn is an absolute minimum compared to any other approach.

Chris




-----Ursprüngliche Nachricht-----
Von: Ben Hutcheson <be...@gmail.com> 
Gesendet: Freitag, 8. Januar 2021 12:49
An: dev@plc4x.apache.org
Betreff: Re: [DISCUSS] mspec a show-stopper? Was: AW: Reflecting on how we volunteer to do stuff

Hi,

I agree mspec certainly simplifies the implementation and it works well.
Some work around updating the documentation would certainly help out though. Then again how many people are actually working with the mspec.

I do think that we can do a better job of advertising how quickly custom protocols can be implemented on the website as it is one of our main features. It might help to grow the number of people working with mspec.

Ben

On Fri, Jan 8, 2021 at 6:23 AM Christofer Dutz <ch...@c-ware.de>
wrote:

> Hi Lukasz,
>
> do you really think mspec is a "show stopper"? ... cause I thought of 
> it more as a "game changer" and an "enabler".
> Cause let's face it: writing drivers for protocols is not a simple task.
> With mspec I think we have reached a simplicity that I haven't seen 
> anywhere before in this sector. And I think seeing that some of our 
> new contributors could just checkout and learn from the exising 
> examples and produce their own mspecs in a short amount of time, 
> proves that it's actually a pretty powerful tool.
>
> I think the protocols you were working on we simply just a nightmare 
> to start with ... no tool will help you with such a task and make the 
> bad dreams go away. Perhaps if you wrote the dirvers manually you 
> would have been quicker in case of CAN.
>
>  I agree that we could need a beginners guide, but currently just 
> don't have the time to write one. I did submit talks and workshops to 
> multiple CFPs now and I hope that from this I'll be able to prepare 
> some content that we can use or even that some recordings might come 
> out of it, which we can link.
>
> And regarding your complaint about using Maven excessively: I agree in 
> the beginning I tried to mavenize the non-java parts, but if you 
> actually had a look recently, that had changed more than a year ago.
>
> Right now every non java part uses the build system native to that
> language:
> - PLC4C uses CMake
> - PLC4CPP usses CMake
> - PLC4Py (the initial version) uses the Python build system
> - PLC4Go uses go
> - In my feature/PLC4Net branch you can use the default .Net build 
> system to build
>
> Even the default directory stuctures were mostly used.
>
> You can even develop in PLC4Go, PLC4C, PLC4C++ by just opeining your 
> IDE of choice in that particular Language. So I don't quite get the 
> point of your complaint.
>
> Yes: in order to generate a new driver in any of these languages, you 
> also need to setup maven in order to generate the code. I even reduced 
> the problems here by checking in the generated code for C and Go. So 
> you really only need to run the maven build to generate, if the mspecs 
> change or you want to add a new driver. The other reason for the Maven 
> integration is simply to have the builds run in Jenkins. Of course we 
> could not do that and setup a Zoo of jobs, each building part of the 
> project, but as I'm currently the only one actually taking care of 
> these plumbing tasks, I'didn't want to do that (And I could see for 
> other projects how bad this actually works)
>
> You could probably change the requirement to run the maven 
> code-generation, but for that you would need to implement the 
> code-generation for those languages/build-systems. Feel free to do so, 
> if this is an itch you feel needs scratching.
>
> What do you others think about this?
>
> Chris
>
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Łukasz Dywicki <lu...@code-house.org>
> Gesendet: Freitag, 8. Januar 2021 00:23
> An: dev@plc4x.apache.org
> Betreff: Re: Reflecting on how we volunteer to do stuff
>
> Its low part of the season. People got locked down in their homes 
> (Poland just entered new year with another lockdown, Germany is same 
> AFAIK), so I am not yet worried by "slowdown" you observe.
>
> I am prime example of someone who has more will that abilities to 
> contribute. You know I stayed around since long time and eventually 
> made few contributions. I think there might be few more like me. I 
> agree with you that making an open community (I think we are) and 
> opportunity to contribute is necessary to give dopamine shots we all need.
>
> Now - in terms of low hanging fruits. I saw very few successful 
> initiatives such this. Main reason why they fail is .. well, people 
> are not often not even aware of them. Making them listed somewhere in 
> JIRA does not help (how often do you look in github 'need helps' issues?).
> Its mainly about making entry point easier for people who use project.
> I know how much effort it was for you to help with Ethernet/IP. You 
> personally helped me with almost every mspec related contribution I 
> made so far. I believe that our main "show stopper" is the mspec. Even 
> existing project staff don't know how to start with it or have 
> troubles with it. If we could publish beginner guide to mspec that 
> could turn into more people trying to write their protocols.
>
> Also we use heavily Maven. While it simplifies life for us (java 
> folks) it makes problems for everyone else. I recall Bjorn complaining 
> about it for
> C(#/++?) stuff. Not all people know how to use it, especially if they 
> are not from old Java landscape.
> Our docs are dug under maven folders making it hard to contribute docs.
> Maybe pulling it up could help.
>
> This are just my free thoughts on how to make it easier.
>
> Cheers,
> Łukasz
>
> On 07.01.2021 10:28, Christofer Dutz wrote:
> > Hi folks,
> >
> > I'd like to discuss something ... something I have been noticining 
> > in
> the last year or so.
> >
> > We're a cool bunch of people, doing awesome stuff. However momentum 
> > in
> the project has sort of slowed down quite a bit. I know we have some 
> great new initiatives going on, but let's say it's become a bit quiet 
> around the folks which have been involved for a longer time period.
> >
> > I would like to get more people involved and active in the project.
> Therefore I would like to strart posting low-hanging fruit here on the list.
> >
> > In the past when I did so, the community was quite fast in raising 
> > hands
> and volunteering to do things. However volunteering is one thing, 
> actually doing seems to be something else. In my impression we could 
> improve on the delivering side. I know we are a volunteer driven 
> community and you are therefore contributing voluntarily in your free 
> time or in the time your company is paying you. But ... keep in mind:
> >
> >
> >   *   If you volunteer to do something, probably others will not raise a
> hand to also contribute. If you now don't deliver what you signed up 
> for, the others won't either.
> >   *   If you volunteer to do something, I will think that this base is
> covered and not jump in (I don't want to interfere in every 
> initiative, but I am happy and willing to help if help is needed)
> >
> > So could you please do me a favour?
> >
> > If I start posting some low-hanging fruit in the near future, please
> consider if you will also have the time to actually do so, before 
> signing up?
> >
> > Chris
> >
>

Re: [DISCUSS] mspec a show-stopper? Was: AW: Reflecting on how we volunteer to do stuff

[Ben Hutcheson <be...@gmail.com>]

Hi,

I agree mspec certainly simplifies the implementation and it works well.
Some work around updating the documentation would certainly help out
though. Then again how many people are actually working with the mspec.

I do think that we can do a better job of advertising how quickly custom
protocols can be implemented on the website as it is one of our main
features. It might help to grow the number of people working with mspec.

Ben

On Fri, Jan 8, 2021 at 6:23 AM Christofer Dutz <ch...@c-ware.de>
wrote:

> Hi Lukasz,
>
> do you really think mspec is a "show stopper"? ... cause I thought of it
> more as a "game changer" and an "enabler".
> Cause let's face it: writing drivers for protocols is not a simple task.
> With mspec I think we have reached a simplicity that I haven't seen
> anywhere before in this sector. And I think seeing that some of our new
> contributors could just checkout and learn from the exising examples and
> produce their own mspecs in a short amount of time, proves that it's
> actually a pretty powerful tool.
>
> I think the protocols you were working on we simply just a nightmare to
> start with ... no tool will help you with such a task and make the bad
> dreams go away. Perhaps if you wrote the dirvers manually you would have
> been quicker in case of CAN.
>
>  I agree that we could need a beginners guide, but currently just don't
> have the time to write one. I did submit talks and workshops to multiple
> CFPs now and I hope that from this I'll be able to prepare some content
> that we can use or even that some recordings might come out of it, which we
> can link.
>
> And regarding your complaint about using Maven excessively: I agree in the
> beginning I tried to mavenize the non-java parts, but if you actually had a
> look recently, that had changed more than a year ago.
>
> Right now every non java part uses the build system native to that
> language:
> - PLC4C uses CMake
> - PLC4CPP usses CMake
> - PLC4Py (the initial version) uses the Python build system
> - PLC4Go uses go
> - In my feature/PLC4Net branch you can use the default .Net build system
> to build
>
> Even the default directory stuctures were mostly used.
>
> You can even develop in PLC4Go, PLC4C, PLC4C++ by just opeining your IDE
> of choice in that particular Language. So I don't quite get the point of
> your complaint.
>
> Yes: in order to generate a new driver in any of these languages, you also
> need to setup maven in order to generate the code. I even reduced the
> problems here by checking in the generated code for C and Go. So you really
> only need to run the maven build to generate, if the mspecs change or you
> want to add a new driver. The other reason for the Maven integration is
> simply to have the builds run in Jenkins. Of course we could not do that
> and setup a Zoo of jobs, each building part of the project, but as I'm
> currently the only one actually taking care of these plumbing tasks,
> I'didn't want to do that (And I could see for other projects how bad this
> actually works)
>
> You could probably change the requirement to run the maven
> code-generation, but for that you would need to implement the
> code-generation for those languages/build-systems. Feel free to do so, if
> this is an itch you feel needs scratching.
>
> What do you others think about this?
>
> Chris
>
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Łukasz Dywicki <lu...@code-house.org>
> Gesendet: Freitag, 8. Januar 2021 00:23
> An: dev@plc4x.apache.org
> Betreff: Re: Reflecting on how we volunteer to do stuff
>
> Its low part of the season. People got locked down in their homes (Poland
> just entered new year with another lockdown, Germany is same AFAIK), so I
> am not yet worried by "slowdown" you observe.
>
> I am prime example of someone who has more will that abilities to
> contribute. You know I stayed around since long time and eventually made
> few contributions. I think there might be few more like me. I agree with
> you that making an open community (I think we are) and opportunity to
> contribute is necessary to give dopamine shots we all need.
>
> Now - in terms of low hanging fruits. I saw very few successful
> initiatives such this. Main reason why they fail is .. well, people are not
> often not even aware of them. Making them listed somewhere in JIRA does not
> help (how often do you look in github 'need helps' issues?).
> Its mainly about making entry point easier for people who use project.
> I know how much effort it was for you to help with Ethernet/IP. You
> personally helped me with almost every mspec related contribution I made so
> far. I believe that our main "show stopper" is the mspec. Even existing
> project staff don't know how to start with it or have troubles with it. If
> we could publish beginner guide to mspec that could turn into more people
> trying to write their protocols.
>
> Also we use heavily Maven. While it simplifies life for us (java folks) it
> makes problems for everyone else. I recall Bjorn complaining about it for
> C(#/++?) stuff. Not all people know how to use it, especially if they are
> not from old Java landscape.
> Our docs are dug under maven folders making it hard to contribute docs.
> Maybe pulling it up could help.
>
> This are just my free thoughts on how to make it easier.
>
> Cheers,
> Łukasz
>
> On 07.01.2021 10:28, Christofer Dutz wrote:
> > Hi folks,
> >
> > I'd like to discuss something ... something I have been noticining in
> the last year or so.
> >
> > We're a cool bunch of people, doing awesome stuff. However momentum in
> the project has sort of slowed down quite a bit. I know we have some great
> new initiatives going on, but let's say it's become a bit quiet around the
> folks which have been involved for a longer time period.
> >
> > I would like to get more people involved and active in the project.
> Therefore I would like to strart posting low-hanging fruit here on the list.
> >
> > In the past when I did so, the community was quite fast in raising hands
> and volunteering to do things. However volunteering is one thing, actually
> doing seems to be something else. In my impression we could improve on the
> delivering side. I know we are a volunteer driven community and you are
> therefore contributing voluntarily in your free time or in the time your
> company is paying you. But ... keep in mind:
> >
> >
> >   *   If you volunteer to do something, probably others will not raise a
> hand to also contribute. If you now don't deliver what you signed up for,
> the others won't either.
> >   *   If you volunteer to do something, I will think that this base is
> covered and not jump in (I don't want to interfere in every initiative, but
> I am happy and willing to help if help is needed)
> >
> > So could you please do me a favour?
> >
> > If I start posting some low-hanging fruit in the near future, please
> consider if you will also have the time to actually do so, before signing
> up?
> >
> > Chris
> >
>

AW: [DISCUSS] mspec a show-stopper? Was: AW: Reflecting on how we volunteer to do stuff

[Christofer Dutz <ch...@c-ware.de>]

Perhaps we could work on this all together?

We yould simply create a new directory in the build-tools repo ... 

I think for now something would be enough to mark where parsing problems are (Pretty much like the ANTLR plugin schows parsed text)

Chris

-----Ursprüngliche Nachricht-----
Von: Otto Fowler <ot...@gmail.com> 
Gesendet: Freitag, 8. Januar 2021 22:59
An: dev@plc4x.apache.org
Betreff: Re: [DISCUSS] mspec a show-stopper? Was: AW: Reflecting on how we volunteer to do stuff

I started a poc plugin for IntelliJ that I will try to work on when I can, but writing a language plugin that does anything substantial is not easy even when you know the language inside and out, and I do not have full time job time to throw at it.

I can’t guarantee I’ll have anything soon, so I’ll un-assign the jira in case I’m blocking


> On Jan 8, 2021, at 15:45, Christofer Dutz <ch...@c-ware.de> wrote:
> 
> I think an mspec-aware editor would eliminate most oft he hard to find difficulties.
> Also I will probably submit a PR to the antlr4 languages repo, as the folks there promissed to give it a spin to iron out the quirks of our lanuage. After all none of us are Antlr4 experts.
> 
> But I am sure that we'll sort out these difficulties.
> 
> However with the Editor ... well we just need people to work on that.
> 
> And any form of help on the documentation is greatly appreciated.
> 
> Chris
> 
> -----Ursprüngliche Nachricht-----
> Von: Łukasz Dywicki <lu...@code-house.org>
> Gesendet: Freitag, 8. Januar 2021 20:16
> An: dev@plc4x.apache.org
> Betreff: Re: [DISCUSS] mspec a show-stopper? Was: AW: Reflecting on 
> how we volunteer to do stuff
> 
> Hi Chris,
> I don't mind mspec as a tool. I do see it to be a game changer and it is a real enabler to write more protocols. I do believe it is a major invention which makes things much better and viable.
> I am also well aware of troubles any first time contributor faces when his excitement leads him to write first protocol. He or she gets a slap, after a slap.
> 
> My concerns are not that the tool is wrong. As I said, its great, but rather hard to use when you do it first and second time (third probably too).
> After all - copy-paste of bigger or smaller chunk from somebody else 
> mspec eventually leaves you with non-working build and no idea what 
> went wrong. Writing first frame which does not use discriminator is 
> straight, but no protocol is so simple. You probably remember mspec 
> documentation PR I made against build-tools repo which put more 
> context into how protocols are constructed and how mspec fits into 
> that. (you can blame me for not bringing it to main repo)
> 
> To outline troubles I found which are worth to document for people who start.
> I had number of situations when my mspec seemed fine, was parsed with no error but some of types got swallowed. I had then to use IntelliJ and check type after type to find where I made a mistake. It took me quite a bit before I learned that I should be starting from last generated type before swallowed one.
> Everyone who wrote mspec also found some reserved names which cause mspec parser to silently fail. However it is not obvious and can depend on actual template used to generate code.
> We also have no documentation on serializer test framework which is great in verifying binary payloads.
> It definitely makes sense to promote (document) these parts to gain other developers traction. I am also one to blame cause once I promised that I will write down my "first timer" experiences and so far haven't done.
> 
> I do not even want to start on conversation context/netty stuff cause its second barrier we have and which have own quirks people learn over time.
> 
> In order to shift load from you and distribute it over others we need to get more people working with mspec and other protocols. They will help project move forward only if them or their companies will achieve own goals at the same time (ie. have custom protocol they want). Surely getting more users taking PLC4X API and interacting with their hardware is important but there is quite long way from using project to maintaining its parts.
> 
> With regard to tooling - if we have cmake in plc4cpp/plc4c/plc4not its final time to call Bjorn to the table. ;-) I do not consider code generation as an blocker. It is not prettiest but I got into troubles there much less often than with other parts.
> 
> Best,
> Łukasz
> 
> 
> On 08.01.2021 12:22, Christofer Dutz wrote:
>> Hi Lukasz,
>> 
>> do you really think mspec is a "show stopper"? ... cause I thought of it more as a "game changer" and an "enabler".
>> Cause let's face it: writing drivers for protocols is not a simple task. With mspec I think we have reached a simplicity that I haven't seen anywhere before in this sector. And I think seeing that some of our new contributors could just checkout and learn from the exising examples and produce their own mspecs in a short amount of time, proves that it's actually a pretty powerful tool.
>> 
>> I think the protocols you were working on we simply just a nightmare to start with ... no tool will help you with such a task and make the bad dreams go away. Perhaps if you wrote the dirvers manually you would have been quicker in case of CAN.
>> 
>> I agree that we could need a beginners guide, but currently just don't have the time to write one. I did submit talks and workshops to multiple CFPs now and I hope that from this I'll be able to prepare some content that we can use or even that some recordings might come out of it, which we can link.
>> 
>> And regarding your complaint about using Maven excessively: I agree in the beginning I tried to mavenize the non-java parts, but if you actually had a look recently, that had changed more than a year ago. 
>> 
>> Right now every non java part uses the build system native to that language:
>> - PLC4C uses CMake
>> - PLC4CPP usses CMake
>> - PLC4Py (the initial version) uses the Python build system
>> - PLC4Go uses go
>> - In my feature/PLC4Net branch you can use the default .Net build 
>> system to build
>> 
>> Even the default directory stuctures were mostly used.
>> 
>> You can even develop in PLC4Go, PLC4C, PLC4C++ by just opeining your IDE of choice in that particular Language. So I don't quite get the point of your complaint.
>> 
>> Yes: in order to generate a new driver in any of these languages, you 
>> also need to setup maven in order to generate the code. I even 
>> reduced the problems here by checking in the generated code for C and 
>> Go. So you really only need to run the maven build to generate, if 
>> the mspecs change or you want to add a new driver. The other reason 
>> for the Maven integration is simply to have the builds run in 
>> Jenkins. Of course we could not do that and setup a Zoo of jobs, each 
>> building part of the project, but as I'm currently the only one 
>> actually taking care of these plumbing tasks, I'didn't want to do 
>> that (And I could see for other projects how bad this actually works)
>> 
>> You could probably change the requirement to run the maven code-generation, but for that you would need to implement the code-generation for those languages/build-systems. Feel free to do so, if this is an itch you feel needs scratching.
>> 
>> What do you others think about this?
>> 
>> Chris
>> 
>> 
>> 
>> 
>> 
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: Łukasz Dywicki <lu...@code-house.org>
>> Gesendet: Freitag, 8. Januar 2021 00:23
>> An: dev@plc4x.apache.org
>> Betreff: Re: Reflecting on how we volunteer to do stuff
>> 
>> Its low part of the season. People got locked down in their homes (Poland just entered new year with another lockdown, Germany is same AFAIK), so I am not yet worried by "slowdown" you observe.
>> 
>> I am prime example of someone who has more will that abilities to contribute. You know I stayed around since long time and eventually made few contributions. I think there might be few more like me. I agree with you that making an open community (I think we are) and opportunity to contribute is necessary to give dopamine shots we all need.
>> 
>> Now - in terms of low hanging fruits. I saw very few successful initiatives such this. Main reason why they fail is .. well, people are not often not even aware of them. Making them listed somewhere in JIRA does not help (how often do you look in github 'need helps' issues?).
>> Its mainly about making entry point easier for people who use project.
>> I know how much effort it was for you to help with Ethernet/IP. You personally helped me with almost every mspec related contribution I made so far. I believe that our main "show stopper" is the mspec. Even existing project staff don't know how to start with it or have troubles with it. If we could publish beginner guide to mspec that could turn into more people trying to write their protocols.
>> 
>> Also we use heavily Maven. While it simplifies life for us (java folks) it makes problems for everyone else. I recall Bjorn complaining about it for C(#/++?) stuff. Not all people know how to use it, especially if they are not from old Java landscape.
>> Our docs are dug under maven folders making it hard to contribute docs.
>> Maybe pulling it up could help.
>> 
>> This are just my free thoughts on how to make it easier.
>> 
>> Cheers,
>> Łukasz
>> 
>> On 07.01.2021 10:28, Christofer Dutz wrote:
>>> Hi folks,
>>> 
>>> I'd like to discuss something ... something I have been noticining in the last year or so.
>>> 
>>> We're a cool bunch of people, doing awesome stuff. However momentum in the project has sort of slowed down quite a bit. I know we have some great new initiatives going on, but let's say it's become a bit quiet around the folks which have been involved for a longer time period.
>>> 
>>> I would like to get more people involved and active in the project. Therefore I would like to strart posting low-hanging fruit here on the list.
>>> 
>>> In the past when I did so, the community was quite fast in raising hands and volunteering to do things. However volunteering is one thing, actually doing seems to be something else. In my impression we could improve on the delivering side. I know we are a volunteer driven community and you are therefore contributing voluntarily in your free time or in the time your company is paying you. But ... keep in mind:
>>> 
>>> 
>>>  *   If you volunteer to do something, probably others will not raise a hand to also contribute. If you now don't deliver what you signed up for, the others won't either.
>>>  *   If you volunteer to do something, I will think that this base is covered and not jump in (I don't want to interfere in every initiative, but I am happy and willing to help if help is needed)
>>> 
>>> So could you please do me a favour?
>>> 
>>> If I start posting some low-hanging fruit in the near future, please consider if you will also have the time to actually do so, before signing up?
>>> 
>>> Chris
>>> 

Re: [DISCUSS] mspec a show-stopper? Was: AW: Reflecting on how we volunteer to do stuff

[Otto Fowler <ot...@gmail.com>]

I started a poc plugin for IntelliJ that I will try to work on when I can, but writing a language plugin that does anything substantial is not easy even when you know the language inside and out, and I do not have full time job time to throw at it.

I can’t guarantee I’ll have anything soon, so I’ll un-assign the jira in case I’m blocking


> On Jan 8, 2021, at 15:45, Christofer Dutz <ch...@c-ware.de> wrote:
> 
> I think an mspec-aware editor would eliminate most oft he hard to find difficulties.
> Also I will probably submit a PR to the antlr4 languages repo, as the folks there promissed to give it a spin to iron out the quirks of our lanuage. After all none of us are Antlr4 experts.
> 
> But I am sure that we'll sort out these difficulties.
> 
> However with the Editor ... well we just need people to work on that.
> 
> And any form of help on the documentation is greatly appreciated.
> 
> Chris
> 
> -----Ursprüngliche Nachricht-----
> Von: Łukasz Dywicki <lu...@code-house.org> 
> Gesendet: Freitag, 8. Januar 2021 20:16
> An: dev@plc4x.apache.org
> Betreff: Re: [DISCUSS] mspec a show-stopper? Was: AW: Reflecting on how we volunteer to do stuff
> 
> Hi Chris,
> I don't mind mspec as a tool. I do see it to be a game changer and it is a real enabler to write more protocols. I do believe it is a major invention which makes things much better and viable.
> I am also well aware of troubles any first time contributor faces when his excitement leads him to write first protocol. He or she gets a slap, after a slap.
> 
> My concerns are not that the tool is wrong. As I said, its great, but rather hard to use when you do it first and second time (third probably too).
> After all - copy-paste of bigger or smaller chunk from somebody else mspec eventually leaves you with non-working build and no idea what went wrong. Writing first frame which does not use discriminator is straight, but no protocol is so simple. You probably remember mspec documentation PR I made against build-tools repo which put more context into how protocols are constructed and how mspec fits into that. (you can blame me for not bringing it to main repo)
> 
> To outline troubles I found which are worth to document for people who start.
> I had number of situations when my mspec seemed fine, was parsed with no error but some of types got swallowed. I had then to use IntelliJ and check type after type to find where I made a mistake. It took me quite a bit before I learned that I should be starting from last generated type before swallowed one.
> Everyone who wrote mspec also found some reserved names which cause mspec parser to silently fail. However it is not obvious and can depend on actual template used to generate code.
> We also have no documentation on serializer test framework which is great in verifying binary payloads.
> It definitely makes sense to promote (document) these parts to gain other developers traction. I am also one to blame cause once I promised that I will write down my "first timer" experiences and so far haven't done.
> 
> I do not even want to start on conversation context/netty stuff cause its second barrier we have and which have own quirks people learn over time.
> 
> In order to shift load from you and distribute it over others we need to get more people working with mspec and other protocols. They will help project move forward only if them or their companies will achieve own goals at the same time (ie. have custom protocol they want). Surely getting more users taking PLC4X API and interacting with their hardware is important but there is quite long way from using project to maintaining its parts.
> 
> With regard to tooling - if we have cmake in plc4cpp/plc4c/plc4not its final time to call Bjorn to the table. ;-) I do not consider code generation as an blocker. It is not prettiest but I got into troubles there much less often than with other parts.
> 
> Best,
> Łukasz
> 
> 
> On 08.01.2021 12:22, Christofer Dutz wrote:
>> Hi Lukasz,
>> 
>> do you really think mspec is a "show stopper"? ... cause I thought of it more as a "game changer" and an "enabler".
>> Cause let's face it: writing drivers for protocols is not a simple task. With mspec I think we have reached a simplicity that I haven't seen anywhere before in this sector. And I think seeing that some of our new contributors could just checkout and learn from the exising examples and produce their own mspecs in a short amount of time, proves that it's actually a pretty powerful tool.
>> 
>> I think the protocols you were working on we simply just a nightmare to start with ... no tool will help you with such a task and make the bad dreams go away. Perhaps if you wrote the dirvers manually you would have been quicker in case of CAN.
>> 
>> I agree that we could need a beginners guide, but currently just don't have the time to write one. I did submit talks and workshops to multiple CFPs now and I hope that from this I'll be able to prepare some content that we can use or even that some recordings might come out of it, which we can link.
>> 
>> And regarding your complaint about using Maven excessively: I agree in the beginning I tried to mavenize the non-java parts, but if you actually had a look recently, that had changed more than a year ago. 
>> 
>> Right now every non java part uses the build system native to that language:
>> - PLC4C uses CMake
>> - PLC4CPP usses CMake
>> - PLC4Py (the initial version) uses the Python build system
>> - PLC4Go uses go
>> - In my feature/PLC4Net branch you can use the default .Net build 
>> system to build
>> 
>> Even the default directory stuctures were mostly used.
>> 
>> You can even develop in PLC4Go, PLC4C, PLC4C++ by just opeining your IDE of choice in that particular Language. So I don't quite get the point of your complaint.
>> 
>> Yes: in order to generate a new driver in any of these languages, you 
>> also need to setup maven in order to generate the code. I even reduced 
>> the problems here by checking in the generated code for C and Go. So 
>> you really only need to run the maven build to generate, if the mspecs 
>> change or you want to add a new driver. The other reason for the Maven 
>> integration is simply to have the builds run in Jenkins. Of course we 
>> could not do that and setup a Zoo of jobs, each building part of the 
>> project, but as I'm currently the only one actually taking care of 
>> these plumbing tasks, I'didn't want to do that (And I could see for 
>> other projects how bad this actually works)
>> 
>> You could probably change the requirement to run the maven code-generation, but for that you would need to implement the code-generation for those languages/build-systems. Feel free to do so, if this is an itch you feel needs scratching.
>> 
>> What do you others think about this?
>> 
>> Chris
>> 
>> 
>> 
>> 
>> 
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: Łukasz Dywicki <lu...@code-house.org>
>> Gesendet: Freitag, 8. Januar 2021 00:23
>> An: dev@plc4x.apache.org
>> Betreff: Re: Reflecting on how we volunteer to do stuff
>> 
>> Its low part of the season. People got locked down in their homes (Poland just entered new year with another lockdown, Germany is same AFAIK), so I am not yet worried by "slowdown" you observe.
>> 
>> I am prime example of someone who has more will that abilities to contribute. You know I stayed around since long time and eventually made few contributions. I think there might be few more like me. I agree with you that making an open community (I think we are) and opportunity to contribute is necessary to give dopamine shots we all need.
>> 
>> Now - in terms of low hanging fruits. I saw very few successful initiatives such this. Main reason why they fail is .. well, people are not often not even aware of them. Making them listed somewhere in JIRA does not help (how often do you look in github 'need helps' issues?).
>> Its mainly about making entry point easier for people who use project.
>> I know how much effort it was for you to help with Ethernet/IP. You personally helped me with almost every mspec related contribution I made so far. I believe that our main "show stopper" is the mspec. Even existing project staff don't know how to start with it or have troubles with it. If we could publish beginner guide to mspec that could turn into more people trying to write their protocols.
>> 
>> Also we use heavily Maven. While it simplifies life for us (java folks) it makes problems for everyone else. I recall Bjorn complaining about it for C(#/++?) stuff. Not all people know how to use it, especially if they are not from old Java landscape.
>> Our docs are dug under maven folders making it hard to contribute docs.
>> Maybe pulling it up could help.
>> 
>> This are just my free thoughts on how to make it easier.
>> 
>> Cheers,
>> Łukasz
>> 
>> On 07.01.2021 10:28, Christofer Dutz wrote:
>>> Hi folks,
>>> 
>>> I'd like to discuss something ... something I have been noticining in the last year or so.
>>> 
>>> We're a cool bunch of people, doing awesome stuff. However momentum in the project has sort of slowed down quite a bit. I know we have some great new initiatives going on, but let's say it's become a bit quiet around the folks which have been involved for a longer time period.
>>> 
>>> I would like to get more people involved and active in the project. Therefore I would like to strart posting low-hanging fruit here on the list.
>>> 
>>> In the past when I did so, the community was quite fast in raising hands and volunteering to do things. However volunteering is one thing, actually doing seems to be something else. In my impression we could improve on the delivering side. I know we are a volunteer driven community and you are therefore contributing voluntarily in your free time or in the time your company is paying you. But ... keep in mind:
>>> 
>>> 
>>>  *   If you volunteer to do something, probably others will not raise a hand to also contribute. If you now don't deliver what you signed up for, the others won't either.
>>>  *   If you volunteer to do something, I will think that this base is covered and not jump in (I don't want to interfere in every initiative, but I am happy and willing to help if help is needed)
>>> 
>>> So could you please do me a favour?
>>> 
>>> If I start posting some low-hanging fruit in the near future, please consider if you will also have the time to actually do so, before signing up?
>>> 
>>> Chris
>>> 

AW: [DISCUSS] mspec a show-stopper? Was: AW: Reflecting on how we volunteer to do stuff

[Christofer Dutz <ch...@c-ware.de>]

I think an mspec-aware editor would eliminate most oft he hard to find difficulties.
Also I will probably submit a PR to the antlr4 languages repo, as the folks there promissed to give it a spin to iron out the quirks of our lanuage. After all none of us are Antlr4 experts.

But I am sure that we'll sort out these difficulties.

However with the Editor ... well we just need people to work on that.

And any form of help on the documentation is greatly appreciated.

Chris

-----Ursprüngliche Nachricht-----
Von: Łukasz Dywicki <lu...@code-house.org> 
Gesendet: Freitag, 8. Januar 2021 20:16
An: dev@plc4x.apache.org
Betreff: Re: [DISCUSS] mspec a show-stopper? Was: AW: Reflecting on how we volunteer to do stuff

Hi Chris,
I don't mind mspec as a tool. I do see it to be a game changer and it is a real enabler to write more protocols. I do believe it is a major invention which makes things much better and viable.
I am also well aware of troubles any first time contributor faces when his excitement leads him to write first protocol. He or she gets a slap, after a slap.

My concerns are not that the tool is wrong. As I said, its great, but rather hard to use when you do it first and second time (third probably too).
After all - copy-paste of bigger or smaller chunk from somebody else mspec eventually leaves you with non-working build and no idea what went wrong. Writing first frame which does not use discriminator is straight, but no protocol is so simple. You probably remember mspec documentation PR I made against build-tools repo which put more context into how protocols are constructed and how mspec fits into that. (you can blame me for not bringing it to main repo)

To outline troubles I found which are worth to document for people who start.
I had number of situations when my mspec seemed fine, was parsed with no error but some of types got swallowed. I had then to use IntelliJ and check type after type to find where I made a mistake. It took me quite a bit before I learned that I should be starting from last generated type before swallowed one.
Everyone who wrote mspec also found some reserved names which cause mspec parser to silently fail. However it is not obvious and can depend on actual template used to generate code.
We also have no documentation on serializer test framework which is great in verifying binary payloads.
It definitely makes sense to promote (document) these parts to gain other developers traction. I am also one to blame cause once I promised that I will write down my "first timer" experiences and so far haven't done.

I do not even want to start on conversation context/netty stuff cause its second barrier we have and which have own quirks people learn over time.

In order to shift load from you and distribute it over others we need to get more people working with mspec and other protocols. They will help project move forward only if them or their companies will achieve own goals at the same time (ie. have custom protocol they want). Surely getting more users taking PLC4X API and interacting with their hardware is important but there is quite long way from using project to maintaining its parts.

With regard to tooling - if we have cmake in plc4cpp/plc4c/plc4not its final time to call Bjorn to the table. ;-) I do not consider code generation as an blocker. It is not prettiest but I got into troubles there much less often than with other parts.

Best,
Łukasz


On 08.01.2021 12:22, Christofer Dutz wrote:
> Hi Lukasz,
> 
> do you really think mspec is a "show stopper"? ... cause I thought of it more as a "game changer" and an "enabler".
> Cause let's face it: writing drivers for protocols is not a simple task. With mspec I think we have reached a simplicity that I haven't seen anywhere before in this sector. And I think seeing that some of our new contributors could just checkout and learn from the exising examples and produce their own mspecs in a short amount of time, proves that it's actually a pretty powerful tool.
> 
> I think the protocols you were working on we simply just a nightmare to start with ... no tool will help you with such a task and make the bad dreams go away. Perhaps if you wrote the dirvers manually you would have been quicker in case of CAN.
> 
>  I agree that we could need a beginners guide, but currently just don't have the time to write one. I did submit talks and workshops to multiple CFPs now and I hope that from this I'll be able to prepare some content that we can use or even that some recordings might come out of it, which we can link.
> 
> And regarding your complaint about using Maven excessively: I agree in the beginning I tried to mavenize the non-java parts, but if you actually had a look recently, that had changed more than a year ago. 
> 
> Right now every non java part uses the build system native to that language:
> - PLC4C uses CMake
> - PLC4CPP usses CMake
> - PLC4Py (the initial version) uses the Python build system
> - PLC4Go uses go
> - In my feature/PLC4Net branch you can use the default .Net build 
> system to build
> 
> Even the default directory stuctures were mostly used.
> 
> You can even develop in PLC4Go, PLC4C, PLC4C++ by just opeining your IDE of choice in that particular Language. So I don't quite get the point of your complaint.
> 
> Yes: in order to generate a new driver in any of these languages, you 
> also need to setup maven in order to generate the code. I even reduced 
> the problems here by checking in the generated code for C and Go. So 
> you really only need to run the maven build to generate, if the mspecs 
> change or you want to add a new driver. The other reason for the Maven 
> integration is simply to have the builds run in Jenkins. Of course we 
> could not do that and setup a Zoo of jobs, each building part of the 
> project, but as I'm currently the only one actually taking care of 
> these plumbing tasks, I'didn't want to do that (And I could see for 
> other projects how bad this actually works)
> 
> You could probably change the requirement to run the maven code-generation, but for that you would need to implement the code-generation for those languages/build-systems. Feel free to do so, if this is an itch you feel needs scratching.
> 
> What do you others think about this?
> 
> Chris
> 
> 
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Łukasz Dywicki <lu...@code-house.org>
> Gesendet: Freitag, 8. Januar 2021 00:23
> An: dev@plc4x.apache.org
> Betreff: Re: Reflecting on how we volunteer to do stuff
> 
> Its low part of the season. People got locked down in their homes (Poland just entered new year with another lockdown, Germany is same AFAIK), so I am not yet worried by "slowdown" you observe.
> 
> I am prime example of someone who has more will that abilities to contribute. You know I stayed around since long time and eventually made few contributions. I think there might be few more like me. I agree with you that making an open community (I think we are) and opportunity to contribute is necessary to give dopamine shots we all need.
> 
> Now - in terms of low hanging fruits. I saw very few successful initiatives such this. Main reason why they fail is .. well, people are not often not even aware of them. Making them listed somewhere in JIRA does not help (how often do you look in github 'need helps' issues?).
> Its mainly about making entry point easier for people who use project.
> I know how much effort it was for you to help with Ethernet/IP. You personally helped me with almost every mspec related contribution I made so far. I believe that our main "show stopper" is the mspec. Even existing project staff don't know how to start with it or have troubles with it. If we could publish beginner guide to mspec that could turn into more people trying to write their protocols.
> 
> Also we use heavily Maven. While it simplifies life for us (java folks) it makes problems for everyone else. I recall Bjorn complaining about it for C(#/++?) stuff. Not all people know how to use it, especially if they are not from old Java landscape.
> Our docs are dug under maven folders making it hard to contribute docs.
> Maybe pulling it up could help.
> 
> This are just my free thoughts on how to make it easier.
> 
> Cheers,
> Łukasz
> 
> On 07.01.2021 10:28, Christofer Dutz wrote:
>> Hi folks,
>>
>> I'd like to discuss something ... something I have been noticining in the last year or so.
>>
>> We're a cool bunch of people, doing awesome stuff. However momentum in the project has sort of slowed down quite a bit. I know we have some great new initiatives going on, but let's say it's become a bit quiet around the folks which have been involved for a longer time period.
>>
>> I would like to get more people involved and active in the project. Therefore I would like to strart posting low-hanging fruit here on the list.
>>
>> In the past when I did so, the community was quite fast in raising hands and volunteering to do things. However volunteering is one thing, actually doing seems to be something else. In my impression we could improve on the delivering side. I know we are a volunteer driven community and you are therefore contributing voluntarily in your free time or in the time your company is paying you. But ... keep in mind:
>>
>>
>>   *   If you volunteer to do something, probably others will not raise a hand to also contribute. If you now don't deliver what you signed up for, the others won't either.
>>   *   If you volunteer to do something, I will think that this base is covered and not jump in (I don't want to interfere in every initiative, but I am happy and willing to help if help is needed)
>>
>> So could you please do me a favour?
>>
>> If I start posting some low-hanging fruit in the near future, please consider if you will also have the time to actually do so, before signing up?
>>
>> Chris
>>

Re: [DISCUSS] mspec a show-stopper? Was: AW: Reflecting on how we volunteer to do stuff

[Łukasz Dywicki <lu...@code-house.org>]

Hi Chris,
I don't mind mspec as a tool. I do see it to be a game changer and it is
a real enabler to write more protocols. I do believe it is a major
invention which makes things much better and viable.
I am also well aware of troubles any first time contributor faces when
his excitement leads him to write first protocol. He or she gets a slap,
after a slap.

My concerns are not that the tool is wrong. As I said, its great, but
rather hard to use when you do it first and second time (third probably
too).
After all - copy-paste of bigger or smaller chunk from somebody else
mspec eventually leaves you with non-working build and no idea what went
wrong. Writing first frame which does not use discriminator is straight,
but no protocol is so simple. You probably remember mspec documentation
PR I made against build-tools repo which put more context into how
protocols are constructed and how mspec fits into that. (you can blame
me for not bringing it to main repo)

To outline troubles I found which are worth to document for people who
start.
I had number of situations when my mspec seemed fine, was parsed with no
error but some of types got swallowed. I had then to use IntelliJ and
check type after type to find where I made a mistake. It took me quite a
bit before I learned that I should be starting from last generated type
before swallowed one.
Everyone who wrote mspec also found some reserved names which cause
mspec parser to silently fail. However it is not obvious and can depend
on actual template used to generate code.
We also have no documentation on serializer test framework which is
great in verifying binary payloads.
It definitely makes sense to promote (document) these parts to gain
other developers traction. I am also one to blame cause once I promised
that I will write down my "first timer" experiences and so far haven't done.

I do not even want to start on conversation context/netty stuff cause
its second barrier we have and which have own quirks people learn over time.

In order to shift load from you and distribute it over others we need to
get more people working with mspec and other protocols. They will help
project move forward only if them or their companies will achieve own
goals at the same time (ie. have custom protocol they want). Surely
getting more users taking PLC4X API and interacting with their hardware
is important but there is quite long way from using project to
maintaining its parts.

With regard to tooling - if we have cmake in plc4cpp/plc4c/plc4not its
final time to call Bjorn to the table. ;-)
I do not consider code generation as an blocker. It is not prettiest but
I got into troubles there much less often than with other parts.

Best,
Łukasz


On 08.01.2021 12:22, Christofer Dutz wrote:
> Hi Lukasz,
> 
> do you really think mspec is a "show stopper"? ... cause I thought of it more as a "game changer" and an "enabler".
> Cause let's face it: writing drivers for protocols is not a simple task. With mspec I think we have reached a simplicity that I haven't seen anywhere before in this sector. And I think seeing that some of our new contributors could just checkout and learn from the exising examples and produce their own mspecs in a short amount of time, proves that it's actually a pretty powerful tool.
> 
> I think the protocols you were working on we simply just a nightmare to start with ... no tool will help you with such a task and make the bad dreams go away. Perhaps if you wrote the dirvers manually you would have been quicker in case of CAN.
> 
>  I agree that we could need a beginners guide, but currently just don't have the time to write one. I did submit talks and workshops to multiple CFPs now and I hope that from this I'll be able to prepare some content that we can use or even that some recordings might come out of it, which we can link.
> 
> And regarding your complaint about using Maven excessively: I agree in the beginning I tried to mavenize the non-java parts, but if you actually had a look recently, that had changed more than a year ago. 
> 
> Right now every non java part uses the build system native to that language:
> - PLC4C uses CMake
> - PLC4CPP usses CMake
> - PLC4Py (the initial version) uses the Python build system
> - PLC4Go uses go
> - In my feature/PLC4Net branch you can use the default .Net build system to build
> 
> Even the default directory stuctures were mostly used.
> 
> You can even develop in PLC4Go, PLC4C, PLC4C++ by just opeining your IDE of choice in that particular Language. So I don't quite get the point of your complaint.
> 
> Yes: in order to generate a new driver in any of these languages, you also need to setup maven in order to generate the code. I even reduced the problems here by checking in the generated code for C and Go. So you really only need to run the maven build to generate, if the mspecs change or you want to add a new driver. The other reason for the Maven integration is simply to have the builds run in Jenkins. Of course we could not do that and setup a Zoo of jobs, each building part of the project, but as I'm currently the only one actually taking care of these plumbing tasks, I'didn't want to do that (And I could see for other projects how bad this actually works)
> 
> You could probably change the requirement to run the maven code-generation, but for that you would need to implement the code-generation for those languages/build-systems. Feel free to do so, if this is an itch you feel needs scratching.
> 
> What do you others think about this?
> 
> Chris
> 
> 
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Łukasz Dywicki <lu...@code-house.org> 
> Gesendet: Freitag, 8. Januar 2021 00:23
> An: dev@plc4x.apache.org
> Betreff: Re: Reflecting on how we volunteer to do stuff
> 
> Its low part of the season. People got locked down in their homes (Poland just entered new year with another lockdown, Germany is same AFAIK), so I am not yet worried by "slowdown" you observe.
> 
> I am prime example of someone who has more will that abilities to contribute. You know I stayed around since long time and eventually made few contributions. I think there might be few more like me. I agree with you that making an open community (I think we are) and opportunity to contribute is necessary to give dopamine shots we all need.
> 
> Now - in terms of low hanging fruits. I saw very few successful initiatives such this. Main reason why they fail is .. well, people are not often not even aware of them. Making them listed somewhere in JIRA does not help (how often do you look in github 'need helps' issues?).
> Its mainly about making entry point easier for people who use project.
> I know how much effort it was for you to help with Ethernet/IP. You personally helped me with almost every mspec related contribution I made so far. I believe that our main "show stopper" is the mspec. Even existing project staff don't know how to start with it or have troubles with it. If we could publish beginner guide to mspec that could turn into more people trying to write their protocols.
> 
> Also we use heavily Maven. While it simplifies life for us (java folks) it makes problems for everyone else. I recall Bjorn complaining about it for C(#/++?) stuff. Not all people know how to use it, especially if they are not from old Java landscape.
> Our docs are dug under maven folders making it hard to contribute docs.
> Maybe pulling it up could help.
> 
> This are just my free thoughts on how to make it easier.
> 
> Cheers,
> Łukasz
> 
> On 07.01.2021 10:28, Christofer Dutz wrote:
>> Hi folks,
>>
>> I'd like to discuss something ... something I have been noticining in the last year or so.
>>
>> We're a cool bunch of people, doing awesome stuff. However momentum in the project has sort of slowed down quite a bit. I know we have some great new initiatives going on, but let's say it's become a bit quiet around the folks which have been involved for a longer time period.
>>
>> I would like to get more people involved and active in the project. Therefore I would like to strart posting low-hanging fruit here on the list.
>>
>> In the past when I did so, the community was quite fast in raising hands and volunteering to do things. However volunteering is one thing, actually doing seems to be something else. In my impression we could improve on the delivering side. I know we are a volunteer driven community and you are therefore contributing voluntarily in your free time or in the time your company is paying you. But ... keep in mind:
>>
>>
>>   *   If you volunteer to do something, probably others will not raise a hand to also contribute. If you now don't deliver what you signed up for, the others won't either.
>>   *   If you volunteer to do something, I will think that this base is covered and not jump in (I don't want to interfere in every initiative, but I am happy and willing to help if help is needed)
>>
>> So could you please do me a favour?
>>
>> If I start posting some low-hanging fruit in the near future, please consider if you will also have the time to actually do so, before signing up?
>>
>> Chris
>>