Star-Demon wrote:
I talked of this a while back and remembered I did a first draft of it for new contributors and a reminder to veteran contributors.

I wanted to make something as generalized as I could. Let me know if some things should be in other places or if there should be more nodes. I love making these and it helps me learn more at a higher level.

EDIT: I'm missing Shoryuken...

Zini wrote:
1. Don't know what you mean with open git.

2. You update your submodules after the merge, not before. And only when it is needed.

4. If you add new files a commit is not enough, you also need to do a git add.

5. We don't require people to make forum posts when they have finished their work. If there is already a thread on the forum, then it can be used. But a large number of development branches go without a single forum post.
I see pushes on github and can act upon them, if it is obvious that they are complete. Alternatively a github pull request is also welcome.

6. Most of time there will be multiple pushes, before it is time for a pull request. We encourage people to push often, even if their work is not finished yet.

7. Before you commit, you should do a git status to make sure that you don't commit accidentally something you did not intended to commit.

As for your comments: I already wrote about #1 and #4

#2: It should build for sure. Testing after every single commit is not required, though some testing is certainly needed. We are fairly tolerant about WIP commits in the github repositories.

Star-Demon wrote:
Well, it IS a first draft...

- A contributor has no way of knowing when a submodule update is needed. If they asked, the only answer they would get is "If you're asking, I guess so." So just do it every time. What is wrong with that?

I should have said mysysgit - I'm mistargetting the flowchart at only windows users.

I'll see if I can make it better sometime.

I wanted to make this since, as you pointed out - there's a lot of procedure getting in the way of work. Anything that simplifies it or takes the memorization out of it helps.

Zini wrote:

- A contributor has no way of knowing when a submodule update is needed.

Sure, he has. Do a git status. If there are some submodule related changes listed after a merge, then one or more submodules were updated.

Doing submodule updates blindly can occasionally get you into trouble too, if you are working on submodules yourself at the same time.

Star-Demon wrote:
Ah - that makes sense.

okay - so I'll remember that.

EDIT: All part of my master plan to post things that are wrong so Zini has to tell us what's right. Bwahahahahaaa!