Create fixing-issues-step-by-step.md

[Trueblueaddie]

[robtuley]

Hi @Trueblueaddie --

Thanks for the contribution! I think I understand the main thrust of the pattern here -- use continuous improvement, a series of small rather than 1 big step -- but what I'm not getting from the pattern as written is how and why this is particularly related to InnerSource?

Maybe this is related to the incubator approach? i.e. start small, incubate through a series of small steps?

I think this needs to have a more InnerSource related angle if possible.

[spier]

Hi @Trueblueaddie --

Thanks for the contribution! I think I understand the main thrust of the pattern here -- use continuous improvement, a series of small rather than 1 big step -- but what I'm not getting from the pattern as written is how and why this is particularly related to InnerSource?

Maybe this is related to the incubator approach? i.e. start small, incubate through a series of small steps?

I think this needs to have a more InnerSource related angle if possible.

@fioddor I have the same question that @robtuley raised above in that I don't see how this pattern is describing a specific InnerSource problem. What are your thoughts here?

[fioddor]

Hi @Trueblueaddie -- Thanks for the contribution! I think I understand the main thrust of the pattern here -- use continuous improvement, a series of small rather than 1 big step -- but what I'm not getting from the pattern as written is how and why this is particularly related to InnerSource? Maybe this is related to the incubator approach? i.e. start small, incubate through a series of small steps? I think this needs to have a more InnerSource related angle if possible.

@fioddor I have the same question that @robtuley raised above in that I don't see how this pattern is describing a specific InnerSource problem. What are your thoughts here?

Summarized: small bits foster external contributions, @spier

I tried injecting more clues into the text (approvals pending), but if you still don't see it, it's a sign that we need to keep on clarifying.

[spier]

@fioddor describing how an "Release early, release often" approach can attract more external contributors to your project sounds like a pattern indeed. How to do reviews in a way that they keep quality high while still being fast (enough) and motivating for the contributors would be super interesting as well.

Right now the pattern sounds it is talking about two different things: On one hand it talks about "process changes". One the other hand there is something related to deadlines and splitting software development into smaller incremental steps. Somehow it seems like both points don't really belong together? I am not sure.

Is it possible that Addie and you were actually after two separate ideas here?

[fioddor]

@fioddor describing how an "Release early, release often" approach can attract more external contributors to your project sounds like a pattern indeed. How to do reviews in a way that they keep quality high while still being fast (enough) and motivating for the contributors would be super interesting as well.

Right now the pattern sounds it is talking about two different things: On one hand it talks about "process changes". One the other hand there is something related to deadlines and splitting software development into smaller incremental steps. Somehow it seems like both points don't really belong together? I am not sure.

Is it possible that Addie and you were actually after two separate ideas here?

I couldn't find anything about "process changes" beyond the suggested change of processing in smaller bits, @spier (?). So I don't see two conflicting points.

The patlet talks about ignoring "scope of change to process" and thereby being unrealistic about deadlines.

[spier]

@fioddor I had misunderstood the "scope of change to process".

I had read it as "scope of change to the process" i.e. a process change. Sorry about the confusion and please ignore that bit of my previous feedback.