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 <[email protected]> Gesendet: Freitag, 8. Januar 2021 12:49 An: [email protected] 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 <[email protected]> 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 <[email protected]> > Gesendet: Freitag, 8. Januar 2021 00:23 > An: [email protected] > 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 > > >
