search

aman-raza / Friends_Hack

Codes with Diversity
MIT License
13 stars 89 forks source link

Can I add my project #126

Closed UG-SEP closed 3 years ago

UG-SEP commented 3 years ago

Hey @aman-raza I wanted to add my few projects in c Please assign me to do that Thanks

cclauss commented 3 years ago

There are two alternative workflows...

  1. Seek permission
    • [ ] Open an issue requesting permission
    • [ ] Wait to be assigned
    • [ ] Get permission and start work
    • [ ] Submit one or more pull requests
    • [ ] Wait for the pull requests to be reviewed and merged
    • [ ] Close the issue
  2. Do the work
    • [ ] Submit one or more pull requests
    • [ ] Wait for the pull requests to be reviewed and merged

Why do so many contributors default to 1. instead of 2.?

UG-SEP commented 3 years ago

@cclauss I try to let you understand with an example Suppose you create a pull request without opening the related issue as if the maintainer didn't what's the change you done then the effort you use to create the PR will be waste so to prevent it we first open a issue then wait till the maintainer didn't reply if the maintainer wants the change then he/she assign you to do the related changes and thus you can prevent the wastage of your time Hope you understand @cclauss

cclauss commented 3 years ago

I believe that:

  1. code is always easier to read, understand, and review than prose is
  2. writing code often makes complexities and corner cases clearer than writing prose
  3. the best time to write up functionality is often when the inspiration strikes and vision is clear
  4. time, interest, and the totally of the vision are often be lost while waiting
  5. code that one maintainer rejects can often be very welcome elsewhere or be the seed from which a new project grow
  6. assigning tasks to one contributor often blocks the creativity of other contributors
  7. if multiple contributors submit similar pull requests it is almost always a learning experience
UG-SEP commented 3 years ago

I believe that:

  1. code is always easier to read, understand, and review than prose is
  2. writing code often makes complexities and corner cases clearer than writing prose
  3. the best time to write up functionality is often when the inspiration strikes and vision is clear
  4. time, interest, and the totally of the vision are often be lost while waiting
  5. code that one maintainer rejects can often be very welcome elsewhere or be the seed from which a new project grow
  6. assigning tasks to one contributor often blocks the creativity of other contributors
  7. if multiple contributors submit similar pull requests it is almost always a learning experience

@cclauss I think every thing in the world have some advantages and some disadvantages it your choice that what you want from ??

UG-SEP commented 3 years ago

@cclauss Can you tell me why there are some rules runs in school this is because they have to manage their work in a manner so the mistake would be less like this if you wanted to run your project you need to create some rules so you can manage your work as a maintainer and think if no one open issue and started creating PR think new about 300 PR have been open so how the maintainer would manage them it would be messy for the maintainer to maintain it. Well i didn't want to say that you cannot create a PR without issue there are many organization work in which you can work without creating issue but they have to many people who work behind it daily Hope you understand and your point of view is not wrong it is right if you see from one edge

aman-raza commented 3 years ago

You guys are awesome, don't get into these sort of arguments Keep learning Learn from each other

Peace :)