You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Despite the presence of documentation and some "HOW-TO" guides, the pacsanini lacks some crucial elements to make it developer/open source friendly.
The CONTRIBUTING guide should be available at the top-level directory of the project to make it easier for newcomers to see how they can contribute.
A CODE_OF_CONDUCT guide should be placed at the top-level directory of the project to better explain what values the project promotes and adheres to.
A release process document should be made to better explain how the project is released so that users and developers can easily see how the project can evolve. Although no releases exist so far, it would be better to anticipate that there will be in the future.
The license to change from GPLv3 to Apache 2.0. The GPLv3 license is too restrictive in my opinion as it prevents the code base to be used in any other context than purely open source. Apache 2.0 (https://choosealicense.com/licenses/apache-2.0/) is quite a popular license choice and would allow for use of this code for private use without having to publish the calling code.
Furthermore, DCOs should be put into place in order to alleviate possible ambiguity as to whether code contributions are OK to use or not (cf. https://github.com/apps/dco).
I would also like to see more in-code examples and use-cases explaining how to use pacsanini and why it can be useful in the documentation. For now, it mostly contains examples from the command-line. However, the "code philosophy" of pacsanini is that whatever is being used as a CLI should also be able to be used inside native python code (which should also allow for more options).
Describe the solution you'd like
I would like the aforementioned documents to be added/modified.
Describe alternatives you've considered
The alternative would be to leave the project without such documents. I fear that this will not encourage external contributions and will limit the impact of the project on the overall community -which is obviously not the goal.
Additional context
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Despite the presence of documentation and some "HOW-TO" guides, the pacsanini lacks some crucial elements to make it developer/open source friendly.
The CONTRIBUTING guide should be available at the top-level directory of the project to make it easier for newcomers to see how they can contribute.
A CODE_OF_CONDUCT guide should be placed at the top-level directory of the project to better explain what values the project promotes and adheres to.
A release process document should be made to better explain how the project is released so that users and developers can easily see how the project can evolve. Although no releases exist so far, it would be better to anticipate that there will be in the future.
The license to change from GPLv3 to Apache 2.0. The GPLv3 license is too restrictive in my opinion as it prevents the code base to be used in any other context than purely open source. Apache 2.0 (https://choosealicense.com/licenses/apache-2.0/) is quite a popular license choice and would allow for use of this code for private use without having to publish the calling code.
Furthermore, DCOs should be put into place in order to alleviate possible ambiguity as to whether code contributions are OK to use or not (cf. https://github.com/apps/dco).
I would also like to see more in-code examples and use-cases explaining how to use pacsanini and why it can be useful in the documentation. For now, it mostly contains examples from the command-line. However, the "code philosophy" of pacsanini is that whatever is being used as a CLI should also be able to be used inside native python code (which should also allow for more options).
Describe the solution you'd like
I would like the aforementioned documents to be added/modified.
Describe alternatives you've considered
The alternative would be to leave the project without such documents. I fear that this will not encourage external contributions and will limit the impact of the project on the overall community -which is obviously not the goal.
Additional context
The text was updated successfully, but these errors were encountered: