Feedback request - Process discussion

[cannawen]

Feedback request - Process discussion

[cannawen]

OHHHHH I GET WHAT YOU MEAN BY TEMPLATES, it's a literal template that github lets you create for issues and PRs. OK. I didn't know those existed. I will add some tomorrow

Edit: also, I am purposefully not tagging issues with "hacktoberfest" to reduce our project's traffic until we figure out a more solid process

[nalinbhardwaj]

Here are my general opinions on the stuff that needs to be worked out in this repo, hope they help, maybe not all of them are on topic, but I think they should be addressed:

1. Instead of using Pivotal Tracker, switch to Github issues exclusively, maybe keep the "ice box" section from pivotal tracker. Since it is not possible for unpaid users to write comments/responses there, it's suboptimal to use that.
2. In most repos I've seen, it is fine to keep assigned for at least 7 days, if someone responds with unwilling-ness, or runs into too many problems to continue, un-assign. Maybe, in case of large tasks, any minor updates in 7 days should continue issue assignment.
3. When merging PRs, squash them into neater single commits with PR number etc., so that it's easier to trace back code from commits to PRs and so on. For example, let summary be something like Feature name(PR #number) and description contain the list of all commits made. I personally prefer this, I don't know about others.
4. Maybe come up with a standard-ish template for PRs(and issues, if needed) where-in it makes sure future readers can easily infer the necessary details of a PR.

[cannawen]

I think you're right, stories should be moved out of Pivotal Tracker so people can comment on them. I also agree with your other points, some guidelines for what information a PR should contain is a great idea! (This is my first open source project, if you can't tell :P)

[cannawen]

@nalinbhardwaj Can you provide an example of what you mean by "a template for issues/PRs"?

I made a first draft of a CONTRIBUTING.md file.

Any comments about the specific text (wording, typos, etc) can be made on the PR.
Any comments about overarching ideas or process-related things can be continued in this thread.

[nalinbhardwaj]

@nalinbhardwaj Can you provide an example of what you mean by "a template for issues/PRs"?

I meant, for issues, we should have some definite fields in title like [bug report], [feature request] etc. in which, an example(for bug report, a link to reddit comment or such), expected behaviour details.

For PRs, a checklist for common things, tested code, reviewed code, follows style guide or similar that can be modified by maintainers etc. You can see PRs like this for example, I like having the Related issues and discussions etc.

I made a first draft of a CONTRIBUTING.md file.

I like the version. By the way, I suggest adding a new file src/testing.js to replicate a reddit comment(body, subreddit etc.) and prints a response as comment with all relevant fields to the console. I don't think it should be hard to write, but it would make manual testing much easier.

[cannawen]

Thank you for the link to the PR and repo, I have stolen some ideas from them :D

I have added "lifecycle of an issue" and "lifecycle of a PR" to the CONTRIBUTING.md doc (which is now merged into master) to describe some flows. I don't think we need tags for PRs because our PRs are generally small, but we can always iterate if we find the current process not working.

I'll leave this issue open for a few more days, if anyone else would like to chime in on process :)