Hello,
After looking at your project github page I have to say that I am underwhelmed and disappointed.
I get the sense that this project, while being actively maintained at the moment, could easily die out, leaving all your users client-less.
Dependencies
First of all, luckily you have a good CI system but guess what - master is currently failing!
* What went wrong:
A problem occurred configuring root project 'client'.
> Could not resolve all artifacts for configuration ':classpath'.
> Could not resolve org.spongepowered:mixingradle:0.7-SNAPSHOT.
Required by:
project :
> Could not resolve org.spongepowered:mixingradle:0.7-SNAPSHOT.
> Unable to load Maven meta-data from http://repo.spongepowered.org/maven/org/spongepowered/mixingradle/0.7-SNAPSHOT/maven-metadata.xml.
> Could not HEAD 'http://repo.spongepowered.org/maven/org/spongepowered/mixingradle/0.7-SNAPSHOT/maven-metadata.xml'. Received status code 520 from server: Origin Error
What is this?
Seriously?
Have you not considered concentration risk?
Do you seriously have only a single maven repository hosting dependencies vital for your project to build, and what's more they're hosted by a third party?
I seriously suggest that you setup a fail safe system for all dependencies.
Ideally you should be operating at least 2 backup maven repositories in separate data centers and political regions in order to prevent issues exactly like this from occurring.
It might also be a good idea to have support for alternative libraries/implementations, so in the case an issue is found with mixin (cyber security vulnerability for example) mixin can be immediately disabled and replaced with a backup library/implementation.
Tests
I almost couldn't believe my eyes when I checked /src/ and discovered that there were no test sources?
Is that a joke?
I hope that the contributors run their own tests before pushing changes, however by not having these tests clearly defined issues can easily arise - what if someone forgets to test? What if someone doesn't bother to test? What if someone's test doesn't cover a certain edge case?
And do the maintainers run any tests before merging pull requests?
And how is the author of a pull request meant to test their own code, after all the contributing guide has no mention of any way that they should.
I highly suggest you set each of your sub projects up as a completely standalone project with it's own build system, ci etc and host them on a public maven repository.
This will allow other members of the community to benefit from your modules rather than using git submodules almost like you are writing C++ with libraries created in the 1950s.
Writing code
As far as I can tell from reading your contributing guide you do not recommend any particular programming methodology which I thought was rather strange.
I propose that all contributors follow the Extreme Programming methodology.
This will bring the following benefits:
Less bugs (partner identifies errors you overlook)
Better security
Better code quality (partner reminds you to format correctly, add comments, etc)
Better problem solving (two minds are better than one)
Better morale (having someone with you to give you motivation helps a lot)
Team building (studies show that having shared accomplishments strengthens bonds)
Of course in these times of mandatory loners, and in the nature of enabling those in geographically remote environments to be able to contribute, I recommend you follow a guide that Todd Sedano (based boomer) wrote on this: http://sedano.org/toddsedano/2016/11/07/remote-pair-programming.html (5 years ago - what a visionary).
Programming Language
I noticed that you are using Kotlin as your primary programming language.
I have several problems with this.
Kotlin is not free.
And by that I mean free as in freedom (of course).
Kotlin is copyrighted by Jetbrains and released under the Apache 2 license, meaning that there are significant restrictions of the distribution of any code in the Kotlin source base and even more so for it's dependencies.
Kotlin is slow.
The parser for Kotlin takes a literal eternity to properly parse anything over 10 lines, making it an absolute pain to develop Kotlin applications on any reasonably large projects.
Since your code of conduct specifies that, quote:
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
How do you intend to allow members of a low socio-economic status to contribute to your project if they need a GTX 3090 Ti just to build it?
Development standards
I was shocked to see that people with the maintainer status are using the online github text editor to submit commits?
This should not be happening, testing can not properly take place if commits are being written in this manner.
I also recommend that instead of pushing directly to master you setup development branches and create pull requests.
By doing this you can ensure that master is always buildable from source.
Inclusion
I am glad that you have a good code of conduct, however I think you need to go further.
I have noticed that your repositories are using the "master" branch as the main branch, have you considered changing this terminology?
I believe that this is in direct contradiction of your own code of conduct.
Github
While the github website is useful for hosting code, there are issues, namely concentration risk and lack of freedom and respect.
It is my recommendation that you setup your own git server on the kamiblue.org website.
Anyway, I hope that this was helpful.
If you have any questions feel free to email me at x4e_x4e@protonmail.com (I only accept signed emails so don't even bother mailing me if you are a gmail normie).
5HT2
commented
3 years ago
Hello, After looking at your project github page I have to say that I am underwhelmed and disappointed. I get the sense that this project, while being actively maintained at the moment, could easily die out, leaving all your users client-less.
Dependencies
First of all, luckily you have a good CI system but guess what - master is currently failing!
What is this? Seriously? Have you not considered concentration risk? Do you seriously have only a single maven repository hosting dependencies vital for your project to build, and what's more they're hosted by a third party?
I seriously suggest that you setup a fail safe system for all dependencies. Ideally you should be operating at least 2 backup maven repositories in separate data centers and political regions in order to prevent issues exactly like this from occurring. It might also be a good idea to have support for alternative libraries/implementations, so in the case an issue is found with mixin (cyber security vulnerability for example) mixin can be immediately disabled and replaced with a backup library/implementation.
Tests
I almost couldn't believe my eyes when I checked
/src/and discovered that there were no test sources? Is that a joke?I hope that the contributors run their own tests before pushing changes, however by not having these tests clearly defined issues can easily arise - what if someone forgets to test? What if someone doesn't bother to test? What if someone's test doesn't cover a certain edge case?
And do the maintainers run any tests before merging pull requests?
And how is the author of a pull request meant to test their own code, after all the contributing guide has no mention of any way that they should.
(currently completing my plumbing Msc)
And what is the point of a CI system if it does not perform any tests?
I almost shutdown my computer after writing this part.
Convulated module system
What on earth are these kind of repositories meant to be doing: https://github.com/kami-blue/event
There is:
I highly suggest you set each of your sub projects up as a completely standalone project with it's own build system, ci etc and host them on a public maven repository. This will allow other members of the community to benefit from your modules rather than using git submodules almost like you are writing C++ with libraries created in the 1950s.
Writing code
As far as I can tell from reading your contributing guide you do not recommend any particular programming methodology which I thought was rather strange. I propose that all contributors follow the Extreme Programming methodology.
This will bring the following benefits:
Of course in these times of mandatory loners, and in the nature of enabling those in geographically remote environments to be able to contribute, I recommend you follow a guide that Todd Sedano (based boomer) wrote on this: http://sedano.org/toddsedano/2016/11/07/remote-pair-programming.html (5 years ago - what a visionary).
Programming Language
I noticed that you are using Kotlin as your primary programming language. I have several problems with this.
Kotlin is not free.
And by that I mean free as in freedom (of course). Kotlin is copyrighted by Jetbrains and released under the Apache 2 license, meaning that there are significant restrictions of the distribution of any code in the Kotlin source base and even more so for it's dependencies.
Kotlin is slow.
The parser for Kotlin takes a literal eternity to properly parse anything over 10 lines, making it an absolute pain to develop Kotlin applications on any reasonably large projects.
Since your code of conduct specifies that, quote:
How do you intend to allow members of a low socio-economic status to contribute to your project if they need a GTX 3090 Ti just to build it?
Development standards
I was shocked to see that people with the maintainer status are using the online github text editor to submit commits? This should not be happening, testing can not properly take place if commits are being written in this manner.
I also recommend that instead of pushing directly to master you setup development branches and create pull requests. By doing this you can ensure that master is always buildable from source.
Inclusion
I am glad that you have a good code of conduct, however I think you need to go further. I have noticed that your repositories are using the "master" branch as the main branch, have you considered changing this terminology? I believe that this is in direct contradiction of your own code of conduct.
Github
While the github website is useful for hosting code, there are issues, namely concentration risk and lack of freedom and respect. It is my recommendation that you setup your own git server on the kamiblue.org website.
Anyway, I hope that this was helpful. If you have any questions feel free to email me at x4e_x4e@protonmail.com (I only accept signed emails so don't even bother mailing me if you are a gmail normie).