First discuss or create issue then work on PR

[rsjethani]

Hey @StefMa @zadjadr I observer that we are creating PR first and then asking discussions on it by that time we have already invested time on it. I come from gitlab world where preferred approach is to create issue -> have a discussion -> agree on requirements/expectations -> then work on pr. For example for this repo #23 and #21 were worked with passion but they did not agree with project expectations. So lets first discuss what is on your mind and then once we agree then we can go on and spend our valuable time on them.

Also lets try a bit better: work on things required by nearest milestone first :)

[StefMa]

Yep, you're right.
I'm sometimes just too passioned about stuff, so I just do the work without question if it's even make sense (for everyone) ☺.

So yes, we should first create an issue - in any cases - and then work on it 👍

[rsjethani]

another advantage of creating issues first is that they can be tracked under milestones

[rsjethani]

I again see multiple PRs etc. focusing on other stuff but #12 for example is still not addressed which belongs to v0.1.0 milestone. There is lot of effort in code and reviews being put in but still we are not ready for first release.
cc @zadjadr @StefMa

[zadjadr]

Yes, you are right. I just implemented the stuff we (sre) need. There is no need to merge or release it immediately.

[rsjethani]

Thanks @zadjadr !!!

[StefMa]

I really appreciate your try to organize this project @rsjethani, seriously.

But honestly, I think it doesn't make sense to hold back features (meaning by that: any PR that add value to this project), only because it doesn't match to the current schedule / milestone. This is not only "against" SCRUM (what we are not doing here, but just wanted to mention this 😂) but it also requires more effort regarding keeping the PR up to date when main changes (that may contain merge conflicts).

Additionally, I can of course only talk from my perspective, I work on this project in my free time. I contribute because I have fun by doing that. In case more and more processes are involved, it will be less fun for me and my contribution would less and less until it drops.

I of course respect maintainers (I guess in this case this is you @rsjethani 😁) choices and decision. And I would also try to follow milestones and release schedules, however, in case I want to work in something else, and I think it bring value to the project, I will do that in favor of sticking to a milestone plan.
The same applies to reacting on issues and PRs. For me it doesn't matter if a feature was planned for version A, B or C. As soon as there is an PR and as long as these changes are small enough to review, I will review it and make anything happen to merge this as soon as possible. Thinking always about it: Someone else spend their time on that. Someone else just did it for fun (maybe) as well. Be nice and welcome anyone and be handsome that this guy or girl contributed! Hell yes, it doesn't matter (for me) if this is someone from the company or someone from outside...

Just my 2 cents about it ✌️

[rsjethani]

Well written @StefMa I agree ... for the most part...I have no issues merging/reviewing things left and right...anything and anyone is welcome...for me the confusion point is that we initially agreed on something but not following it...because giving a good code review also take time...free time...

But I take this discussion as a cue and not to meddle too much and go with the flow... 👍