newbie: should git bare repositories (forked ones) have an origin defined?

Yesterday I forwarded a question related to setting up public repositories and flows. Related to that question, and central to one point I do not understand, is not so much the role of origins, but rather their application.

Given the following scenario, who defines origins, and where?

repositories : product.git, product-next.git, product-story-or-module.git, product-maint.git

The idea here would be to have product-next.git and product-maint.git repositories to be public repositories forked from product.git.

What I have read in the Oreilly Git book is that when you `init --bare` there are no defined remotes, nor are there any branches. So how specifically should these repositories be set up?

Here is a guess, but likely incorrect...

Master:

git init --bare product.git git init product-init.git cd product-init.git git remote add origin ../product.git touch README echo "hello world" > README git add README git commit -m "initial checkin" git push origin master

Next:

git clone --bare --no-checkout product.git product-next.git cd product-next.git git remote add upstream ../product.git

Comments:

When I create a local clone of "next" and inquire about remote refs, there are none for "upstream". What I had thought was that by adding in predefined remote refs into the forked repository itself that when developers clone from it they would get those predefined refs for free, so they could immediately make use of "upstream" in push/pull operations.

Question:

Is what I am inquiring about reasonable, or is there a good reason to not have remote refs embedded into the public forked repository? How should public forked repositories ("next" in the use case above) be initially created on its host?

Thank you,

Bob