New Contributors/Maintainers

[karbassi]

From @karbassi on August 11, 2017 20:57

I'd like to start off this community fork on a strong foot to allow for open dialog and easy management.

Proposed

• There should be a Code of Conduct created for all to follow. (Create CODE_OF_CONDUCT.md #217)
• We should follow some sort of git branch model.
• There should be only the owners (currently 3) who have merge permissions into stable branches. (see below)
• All changes should go through a pull request, even from project maintainers. (see below)
• All pull requests must have tests, which pass via a CI tool (travis-ci has been already been set up).

Branch Model

My thoughts are to have master as the latest released version and develop as the latest staged version. This would allow the team to have a "beta" on develop if need be.

Merge permissions

It would be great to have one or two individuals who are the gatekeepers with merging permissions. I'd like to have everyone commit and be part of the project, but only a few who are in charge of making sure the PRs are valid, tests have been ran and passed, and the PR is for the best of the project.

Please add your thoughts and comments.

Copied from original issue: todotxt/todo.txt-cli-fork#9

[karbassi]

@inkarkat I'd love your thoughts on this as you are very active on the project and I would like to add you as a co-maintainer. I would love for us to start off on the same page.

[karbassi]

@ginatrapani thoughts?

[ginatrapani]

There should be a Code of Conduct created for all to follow. (#217)

Agree! And the first PR looks great. Something to keep in mind: Todotxt encompasses many projects (CLI, mobile apps, etc), so we should decide if we want to duplicate the CoC across repo's or reference the one in one of the repo's in the others.

We should follow some sort of git branch model.

Yep, master and develop sound fine to me.

There should be only 1 or 2 people who have merge permissions into stable branches.

Based on our experience of the project so far, I highly recommend having more than 1 person with merge permissions. Ideally it's at least 3. Two would be okay. This is a long game, and a huge commitment, and it's difficult for a single person to be responsive over the long haul -- people go on vacation, get busy, have periods of time when they are more interested/patient/available than others. Fwiw, I'd like to be one of the people who get merge permissions in the new org.

Also, if someone with merge permissions doesn't respond to or merge anything in the org for, say over 3 months, that person should lose those permissions.

All changes should go through a pull request, even from project maintainers.

Definitely.

[inkarkat]

There should be a Code of Conduct created for all to follow. (#217)

It's mostly common sense, but I think it's good to make this explicit. It's a bit like insurance: You hope you'll never need it, but it's good to have in case of problems.

We should follow some sort of git branch model.

This is modeled after git-flow, right? I don't like the default naming and prefer to have the development done on master as in standard Git (and instead have a stable branch for releases). But here it might make sense to have the stable stuff on master: People who are not so tech-savvy probably would just download the Git repo based on the default branch, and it's good that they'll get a stable release then.

There should be only 1 or 2 people who have merge permissions into stable branches. (see below)

In the beginning, it probably will be just the two (three with Gina) of us. I would be willing to give others permissions, once they've proven to be reliable (through a few successful pull requests), if they indicate a long-term interest. I don't think this will happen (often / at all), though.

All changes should go through a pull request, even from project maintainers. (see below)

Yes, that's a good practice. No one should single-handedly take the project in some direction. This also ensures that new features are properly documented and don't just suit a single user.

All pull requests must have tests, which pass via a CI tool (travis-ci has been already been set up).

There are some things that the current test framework doesn't cover (my recent pull request that suppresses error message in the completion, for example). However, in general we should ask for test coverage, and not accept pull requests that don't have any, or fail the existing tests. Sometimes people provide nice additions, but then don't follow up with tests. That's a touch choice, then.

[karbassi]

I highly recommend having more than 1 person with merge permissions. Ideally it's at least 3.

Agreed. I've updated the # in the original comment.

---

That said, looking at the previous comments, I think we are all in agreement. @ginatrapani @inkarkat Please thumbs down/up this if you dis/agree so we can close the comment or keep the discussion going.