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

[Robert Buck <buck.robert.j@gmail.com>]

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