NguyenDanPhuong / MangaRipper

This software helps you download manga (Japanese Comic) from several websites for your offline viewing.
MIT License
189 stars 43 forks source link

Lack of communication? #138

Closed GambitKZ closed 5 years ago

GambitKZ commented 6 years ago

I try not to make a lot of changes in the architecture because I don't know what kind of vision do you have regarding the affected code and how I broke the whole project out of the course with it. There are also were some cases when I try to implement some kind of feature, and on the next day, I found that the core code SUDDENLY was changed. It's not a bad thing by itself, it should be updated. But if I knew about those changes beforehand I would wait for those new changes to be in dev, which will save me from the additional work of changing the big part of the code before creating the pull request (if not drop it idea altogether).

How about creating some kind of paragraph with "Incoming changes" in "README.md", or create the "Project board" and add the task (not sure how it's shared in GitHub), or do something else but in a way so it will be visible for other contributors. Because currently the only one who can see the whole picture, where should it go and how is it now - is you, and only you. Of course, you are the boss, and you the one who set the path for the whole ship, but it would be better if the sailors knew what captain wants and try to do the changes according to the plan.

So I have the following concerns:

  1. Due to the poor communication, I don't know what am I allow to change and what not. What will be changed in a couple of days in the original code and broke all the previous logic, and what will happen in a month.
  2. Due to the first point, I try to make a feature with fewer code changes hoping that it will be merged in dev and later changed according to your vision. (Which usually happens before. After my commits there are a number of your commits with code refactoring)
  3. Due to the first two points, I'm not so motivated in creating something new because I don't know what will happen - We get breaking changes in the code before/after the pull request was created or the code which was created is a duplicate of the code which someone has done and commit some hours ago before my pull-request.

All I want to say - we have a lack of communication and we need to do something with it.

OR, maybe I'm the only one who sees the problem in this and it's better to leave everything as is. Anyway, I like to hear the thoughts of everyone.

@NguyenDanPhuong @JedBurke @Danatobob

NguyenDanPhuong commented 6 years ago

Hi @GambitKZ

I agree that there's problem. But mostly due to this project is not my daily task. I've checking it about 1 per week or, sometime, month. If I communicate daily, it wouldn't a problem.

Currently, MangaRipper has a good software design, with all the features and supported sites. The code still easy to read, understand and navigate. I plan to keep it that way.

When you implement something, even if I have to change it. You can compare your implementation with my implementation. By that, you improve in software design. It's win-win situation. :)

However, to make it easier for me to merge your pull request. Please split it to many small pieces (by feature) instead of a big piece. For example, you can create a pull request for fixing MangaFox and another one for renaming.

The workflow is: create a branch from my code, change then create pull request. After that create another branch from my code again, change then create another pull request. Each pull request is from a different branch.

A project to manage tasks may work but usually when I've adding a new feature from start to finish, it takes 2-3 hours. So it too fast for other to look at the project and know what I'm doing.

GambitKZ commented 6 years ago

Hi @NguyenDanPhuong

For example, you can create a pull request for fixing MangaFox and another one for renaming

Yep, that was my blunder. I have tried to do everything in one swoop with thoughts that it will be merged together.

it takes 2-3 hours.

Ok, it's the time of implementation. However, Idea itself set in your head much earlier than this. And this is the part which I want you to share with us. e.g. "Guys, I want to implement 'IoC' soon, stay tuned".

Others didn't write anything here, so I can assume that this question bothered only me.