jwt-auth
jwt-auth copied to clipboard
PHP-Open-Source-Saver
Suggestion documentation
As we forked this package from Tumondesigns we need to give him the credits in the default readme.MD and remove the wiki that he created and create on our own (it's not fair we use his stuff to our benefit).
Suggestion from my side:
1 - let's create a new readme. MD. 2 - create a new wiki of documentation (might be will be necessary 1 - 2 people working on that to keep it up as maximum posted). 3 - take all the issues from the original repository and post them here. 4 - get all the opened (relevant) PR and reopen here.
And by the end, remove the direct dependency of the fork of his repository (otherwise will be like another contributor).
We need also to register the package on packist and change the namespaces.
There's a lot of work to do just for the beginning before we proceed with the evolve of the package.
I have added a posting in the discussions area about how we could start: https://github.com/PHP-Open-Source-Saver/jwt-auth/discussions/1 I thought that the discussion on how to proceed would be better served there. I would use the issues for problems/feature requests and discussions to coordinate work. But we can also use the issues for both. I'm fine with this.
I think your points are very good. The documentation really needs to be updated. Would you like to use the Wiki inside Github or with some linked markdown documents?
I am going to contact the support and ask if the fork-dependency can be removed.
I have added a posting in the discussions area about how we could start: #1 I thought that the discussion on how to proceed would be better served there. I would use the issues for problems/feature requests and discussions to coordinate work. But we can also use the issues for both. I'm fine with this.
I think your points are very good. The documentation really needs to be updated. Would you like to use the Wiki inside Github or with some linked markdown documents?
I am going to contact the support and ask if the fork-dependency can be removed.
1 - About the documentation: I believe for better continuous integrations and reliability of the documentation is for us to keep it as a Github wiki or readme markdowns, not a website.
Since this is an open-source package and I expect in the future we have a lot of maintainers we can keep it up posted in a single source of everything it'll be easier.
2 - About the dependency:
Yes, we need to check how to remove it and continue it as an independent package and ALWAYS remember in the main readme give the credits for the original author, but also, keep it clear that'll be an independent package maintained by us trying to attempt the best interest of the open-source community.
3 - About the packist:
Might be will be interesting to have an account in packist with the email associated with the organization where the founders can have access on and only one founder can have the ability to recover it if necessary (to avoid scams and that stuff) and check-in packist if there's the same feature in the GitHub to keep other people on there as maintainer.
These 3 points I believe it's a good kickstart for us to start making the package go forward and avoid our projects has legacy code . Here, for example, we always use the latest version, so soon or later the primary package might be will become a headache for those who use it.
1 - Documentation: I think it's better to have the documentation as markdown documents, so that you able to access it locally if needed. Additionally the history of the documentation is preserved.
2 - Dependency I have contacted the support. The dependency should be removed in a while.
3 - Packagist I don't have any experience with publishing on packagist. Do you have any experience in this field?
I think the best approach is to create for every of the different steps an issue. Then we can assign these issues to different persons who want to take over these tasks.
1 - Documentation: I think it's better to have the documentation as markdown documents, so that you able to access it locally if needed. Additionally the history of the documentation is preserved.
2 - Dependency I have contacted the support. The dependency should be removed in a while.
3 - Packagist I don't have any experience with publishing on packagist. Do you have any experience in this field?
I think the best approach is to create for every of the different steps an issue. Then we can assign these issues to different persons who want to take over these tasks.
1 - Sure, let's keep going at this, let's wait for fork dependency to be removed. 2 - Let's wait. 3 - Me too, I usually collaborate, but anyway even I was experiencing that only the owner of the organization should register the package.
So I just got the message, that the dependency has been removed.
Then I will have a look how to publish on packagist :)
I will open new issues for the different tasks. Feel free to extend if there are any information missing.
So I just got the message, that the dependency has been removed.
Then I will have a look at how to publish on packagist :)
I will open new issues for the different tasks. Feel free to extend if there is any information missing.
Great, before see how to publish the package, we need to change all the namespacing.
@eschricker did you registered the package in packist to we start using it at our projects?
I just registered the package :)
https://packagist.org/packages/php-open-source-saver/jwt-auth
When the pull requests are alle merged, I am going to release a first new version.
Ok, so let's finish those merges to try release this package at least by the end of the month.
That is a good plan. Do you have more pull requests from the origin repo in mind, which needs to be migrated in here? I think you have a better overview about them compared to me.
Regarding the luccobuci and my, the others ones need to check one by one because not everything wrote down PR's and there's a lot PR's already :(
What I think is good for us to do is go there and let them more people are working to keep the package going forward and they start contributing here too.
For documentation deployment, I think Github's Wiki isn't great solution, since documentation should be versioned. Personally, I think it would be great to use Pages for deployment, and some tools like MKDocs or Vuepress
For documentation deployment, I think Github's Wiki isn't great solution, since documentation should be versioned. Personally, I think it would be great to use Pages for deployment, and some tools like MKDocs or Vuepress
You're right, we should put this on the road map, can you open an issue for us to open in the roadmap?
Don't think we need special issue for documentation roadmap. I see our current steps following:
- [x] Find our way to deploy current documentation somewhere (https://github.com/PHP-Open-Source-Saver/jwt-auth/issues/61)
- [ ] Update existing documentation to fill missing gaps and new features
Don't think we need a special issue for the documentation roadmap. I see our current steps following:
- [x] Find our way to deploy current documentation somewhere (Deploy documentation #61)
- [x] Update existing documentation to fill missing gaps and new features
To quickstart, we should use the same model of the tymons documentation because some stuff is already done and documented out there, so I don't see why we should rewrite it.
And might be for new PR for new features that would be usable by the programmer we should add it straight to documentation too.
This issue was resolved in the new releases and since there are no new functionalities and only adaptations to new PHP versions we'll not need to update the doc.