The future of Redstone (change control and stuff)

[austincummings]

Hello everyone,

Now that this project is driven by the community (and 7 of us have the ability to push changes), I think it's best if we define some processes (fun huh?) in order to keep this project in the nice state it has been. In my experience we need the following:

• Bug priority tracking
• Feature proposal process
• A clear cut roadmap with milestones
• Change control

If any of you can think of any other things we need to consider before going any further with the project feel free to bring them up.

Thanks guys.

[azenla]

@austincummings Bug priority tracking is good. I propose we have 3 priorities, and use labels of P1, P2, P3.

[cgarciae]

@kaendfinger Nice!

How about a v0.6.md to define features, goals, intentions, etc, in words and code snippets. We can discuss its content in an issue.

[azenla]

Labels P1, P2, P3 have been added.

Feature proposal process, we will probably need to discuss this thoroughly.

[azenla]

@cgarciae Sounds good! In the v0.6 branch?

[austincummings]

@kaendfinger So which is highest priority? Maybe Low, Med, and High are better for this?

[azenla]

@austincummings Good idea. I'll do that. I got this idea from dartdoc's repo, which has P1-P3

[cgarciae]

@kaendfinger Lets all work in the v0.6 branch but create a new folder structure like this roadmaps/v0.6.md

[azenla]

Ok :)

[azenla]

@cgarciae https://github.com/redstone-dart/redstone/blob/v0.6/roadmaps/v0.6.md

[austincummings]

As for change control I think we need to have code be reviewed before it is committed to the default branch. Make the change in a branch and submit a pull request which will trigger the review process. Also each change should be associated with an issue. This may be a bit cumbersome but it will truly improve the quality of the code.

Edit: For typo fixes and stuff like that we don't need a review.

[azenla]

@austincummings PRs are issues but with a patch for it. I disagree with every change to an issue. Bugs should have issues, but not everything.

[azenla]

@austincummings: Your edit solves that comment :)

[austincummings]

@kaendfinger, oh right. I've been using svn for too long.

[azenla]

:)

[austincummings]

Each major, minor, but not trivial change shall have an issue associated with them.

@redstone-dart/owners Everyone agree with this?

[mbullington]

Sounds good.

[azenla]

I agree. Trivial should be clearly defined. As I see it, this is what defines trivial:

• Not a feature
• Not a code fix
• Documentation typos
• Other typos

[cgarciae]

@kaendfinger @austincummings The Github App for windows has me a little confused with the new permissions. Do I fork into cgarciae or is there a better way?

[azenla]

@cgarciae For committing, you can just create a branch on this repository from the v0.6 branch. That's what I did with #103

[austincummings]

@kaendfinger That definition works for me.

@cgarciae so I think creating a branch and then making a pull request to the main branch should work to get the code review process going. If it's a trivial change you can skip the review process

[cgarciae]

@kaendfinger @austincummings Ok, sounds a little scary. I like the isolation forks provide, I guess branches also provide that isolation but you have to be more careful. (Sorry for the paranoia, I work with a close friend who is really bad at Git so I am always scared of him committing directly)

[austincummings]

@cgarciae I see your point. I have absolutely committed to the wrong branch before. I agree creating a fork on our own user accounts would be best to avoid any trouble.

[azenla]

@cgarciae Oh I fully understand :) You can fork it if you want, but you don't have to :)