[DOCS] Add CONTRIBUTING.md file about abbreve HOT 25 CLOSED

Let them work on that part, so I can just update it with the remaining info so as not to have any merge conflicts arising

from abbreve.

Also wanted to say 5 isn't necessary. A spell checker is cool, but we shouldn't get people to install an additional extension for something we can help them fix... It makes sense, but I don't know. I'd love to hear thoughts on this.

Yes! I thought about this too, contributors shouldn't have to be obligated to install any external resources.
Will replace 5 with Check your new additions for typos before commiting.

Conclusion

Remove 4 & 6
Modify 5

from abbreve.

@theselaw this is a great idea and I can incorporate it in the section I'm working on

from abbreve.

@akebu6 I am done with my part. Although, a some the inclusions I made to the file coincided with the last two sections you are handling. I suppose you can review it and add your input wherever it is required.

Sure, I will look at it tomorrow and complete the remaining sections

from abbreve.

I'd like to work on this

• What kind of contributions are we looking for?

from abbreve.

Feel free @slim-codes I'll assign this to you!

from abbreve.

What parts of this document are being worked on and which aren't?

from abbreve.

I think @slim-codes wants to write about the kind of contributors we are looking for. I think you can go ahead and start work on this.

from abbreve.

@slim-codes are there any updates on this?

from abbreve.

@akebu6 I think it's safe to start work on this.

from abbreve.

@slim-codes are there any updates on this?

Yeah! I'm almost done here. Just a few more hours
Been having some power issues

from abbreve.

@akebu6 How about you start working on the last two sections pending when I complete the first 2:

• Commit conventions, issue, and pull request templates
• Links to resources, the code of conduct, etc

from abbreve.

@slim-codes yeah I can do that

from abbreve.

@Njong392
In the What kind of contributions we are looking for section I included the following:

1. You can append common abbreviations/acronyms used for communicating through the internet (social media) to the list of definitions.
2. Do not make duplicate entries (always confirm that an entry does not exist by searching through the the json file
3. Only English abbreviations are currently allowed
4. Only include abbreviations/acronyms in the database nothing else. Do not append internet slangs to the database (e.g guru, geek, troll, noob, etc). It's strictly meant for abbreviations
5. Use a spell checker to verify that there are no spelling errors in any of your entries. You can install Code Spell Checker: A VSCode extension that catches spelling errors to ensure that your entries are free of spelling errors.
6. Your PR should not contain more than 20 entries. If your entries exceed 20, make a separate PR for each. This is to make it easier for the maintainers to review your entries and revise them if the need arises
7. Your entries should be in Sentence Case (e.g lgtm: Looks Good To Me not looks good to me)

Now, what's your take on these, particularly 3, 4, and 6. Plus if there's any guideline I haven't included please specify before I make the PR.

Note:

• The above guidelines will be arranged with a bulleted list, I numbered them here for reference purpose
• I have already prepared the guidelines for forking, cloning and pushing. I just need to get you take on the above.

from abbreve.

3 looks okay to me. As for 4 it's not very clear yet. We can work on that during PR reviews. Same goes for 6. I don't think there's any need to restrict the number of PRs someone makes. We can address that during reviews. So i suggest taking out 4 and 6 for now. What do you think?

from abbreve.

Also wanted to say 5 isn't necessary. A spell checker is cool, but we shouldn't get people to install an additional extension for something we can help them fix... It makes sense, but I don't know. I'd love to hear thoughts on this.

from abbreve.

3 looks okay to me. As for 4 it's not very clear yet. We can work on that during PR reviews. Same goes for 6. I don't think there's any need to restrict the number of PRs someone makes. We can address that during reviews. So i suggest taking out 4 and 6 for now. What do you think?

Alright then. Just wanted to be sure. BTW 6 isn't a restriction on the number of PR's but a restriction to the number of new entries in a single PR. However, considering the plans for making each acronym have it's independent JSON, 6 becomes unnecessary as you said.

• since 4 isn't clear yet, we should remove it too

from abbreve.

@akebu6
I am done with my part. Although, some of the inclusions I made to the file coincided with the last two sections you are handling. I suppose you can review it and add your input wherever it is required.

from abbreve.

@Njong392 isn't there a way for users to contribute from github directly ?

If there is ,it would be nice If this can be included in the documentation.
Would love to be assigned that too.

Thanks.

from abbreve.

@theselaw this is a great idea and I can incorporate it in the section I'm working on

Alright,If there's any way I can contribute to that,please let me know.

Thanks.

from abbreve.

Reopening this to keep up with conversation.

from abbreve.

Just saw this. I guess we need to update this document with the changes made in #108 after reviews

from abbreve.

@slim-codes I am going to add the alternative of using GitHub when creating issues and the like because some people are not comfortable with using CLI

from abbreve.

@akebu6
Yeah! That's a good idea.
Considering code/documentation changes can also be done straight from the GitHub UI.

from abbreve.

@slim-codes that's very true because not everyone is comfortable with working with CLI

from abbreve.