Feedback request - Process discussion

[cannawen]

EDIT: CONTRIBUTE.md document created, but feel free to keep discussing process-related improvements that can be made

---

Hey everyone!

I am having some problems with our current process, where Alice volunteers to fix an issue, but then Bob makes a PR for it (either not noticing the "already-assigned" tag, or they started working on it without commenting on the issue). There are also times I don't know a story is being worked on, and suddenly a PR appears. It's awesome that unexpected features are "magically" getting done, but also a bit scary

While it's amazing to have so much interest, I feel like this lack of transparency is not sustainable because there may be duplicated efforts (and that would 100% suck).

I am thinking of making a CONTRIBUTING.md document that states if you start working on something, you must make a github issue to let everyone else know. Some concerns/questions I have: 1) Should PRs without open github issues be rejected? Perhaps if there is no conflict, the PR can be accepted with a warning for next time? 2) If someone opens a PR for an issue they were not assigned, should the PR be rejected? What if the original assignee does not finish the issue? 3) How long should an issue be assigned to a person for? Should we enforce a "deadline" for when a feature must be done?

I am opening this issue for discussion, has anyone else run into this kind of problem before? Can anyone think of a good solution? Any thoughts or feedback are welcome.

[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 :)

[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