If you are implementing a new feature, you want to discuss it with the maintainer first.
Josh, a member of the DevRel team, once spent two days implementing a new command format for JAWS (the predecessor to the Serverless project, which automates a lot of the work to create AWS Lambdas). He submitted the PR, only for it to be rejected. He made a radical change to the command format that broke backwards-compatibility. If he had discussed it with the maintainers first, he would have taken a different approach, or not even done it.
Don't be like Josh. Be in communication from the beginning.
Once you get an approach to use, you'll do your implementation. Remember to write tests for it, following the tests in the project.
When you submit the PR, you may get some feedback from the maintainer.
If you don't have time to make the requested changes, let the maintainer know. We appreciate that you are doing this on your own time, and have other things that you need to do.
The maintainer may be able to make the changes in that case. Or someone else in the community could pick it up. Be in communication.
If you can make the changes, this is a great opportunity to learn. It could be about the coding conventions in the project, or some technical aspect of the code itself.
Zoltan, an engineer in the Camunda Cloud team, once submitted a Pull Request to an open source project, with a testing framework in it. After discussion with the maintainer, it turned into a separate project, as a plugin. Six weeks later, and after working with several members of the project to shape the implementation, he ended up with a significant contribution to the community and a lot of new knowledge.
How much time you can spend on a Pull Request, and how inspired you are to do it, varies. Obviously, if you can take it all the way, it has a greater chance of getting merged - and you'll experience a greater sense of accomplishment.
And even if you can't take it all the way, you'll learn something.