I have some guesses about the evolution of the "stub" concept on Wikipedia and am seeking information from oldtimers as to whether my guesses are right.
I first encountered the word "stub" in a technical context. About the time I started hearing about "top-down programming," which would have been, um, the 1980s, I also started hearing about "stubs."
When you are following the top-down methodology, you often encounter a situation where subroutine A calls (and hence depends on) subroutine B. Yet you want to write and test A before B is written.
For example, subroutine A might call subroutine B to find out whether a device is ready before trying to output to it. Subroutine B is absolutely vital to the finished program, but for purposes of writing and testing A you just write a "stub" version of B which doesn't actually talk to the device, but just says "the device is ready."
In this context, a stub is a piece of temporary scaffolding that is put in place solely to allow work to proceed, which is not a part of the finished product, and which must be removed and replaced with the real subroutine before the product is released.
I fantasize that it is a couple of years ago, and that there are enormous numbers of articles that anyone can see need to be written, and that I have decided to write about (say) echinoderms. As I start to write, say, an article on "Echinodermata," I realize that I will eventually want to write and link to Asteroidea, Echinoidea, etc. So I create stubs for these, with two things in mind. First, I have at least some intention of going back and actually writing those articles. Second, I know that there are other people who know as much or more than I do about echinoderms, and may prefer to write the article on Asteroidea myself rather than waiting for me to do it.
So the stub serves _three_ purposes: a reminder to everyone that there's an article that needs to be written, an implied statement that I sort of plan to write that article when I get around to it, and an implied invitation to others that if they feel like working on this _before_ I can get around to it, they should just jump in.
I notice that "The Perfect Stub" clearly presents stubs in the context of an intention by the creator of the stub to continue personally working on expanding the stub. It seems to suggest that the expected timeframe for this expansion is a few weeks; that is, it should reasonably expected that the stub contributor will keep nibbling away, adding small accretions to the stub, and that if a few weeks have elapsed and nobody else has taken on the job of writing the article the stub creator should assume that nobody else is going to, and they should write the article themselves.
Part and parcel of this viewpoint is that a stub is not useful in itself. As with the programmer's stub, it is just a temporary expedient to allow work to continue, and must be replaced with a real article before "release."
Does this imaginary view of mine correspond to an historically correct description of the mindset with which stubs were viewed a couple of years ago?
As you describe in programming, a stub is a development construct. With concurrent development by more than one programmer working together toward a common goal, user "Zero0000" may create a stub, which is expanded upon by user "Lance6Wins" and brought to release quality by user "Viajero". The process may be iterative and each may add at various times.
Seems to map very well to the concept of stubs in Wikipedia.
Lance6Wins.
(names chosen totally at random by "the Forlorn Hope". hmmm...do we have a wikipedia page on "the forlorn hope"? bit of british army history there.)
--- dpbsmith@verizon.net wrote:
I have some guesses about the evolution of the "stub" concept on Wikipedia and am seeking information from oldtimers as to whether my guesses are right.
I first encountered the word "stub" in a technical context. About the time I started hearing about "top-down programming," which would have been, um, the 1980s, I also started hearing about "stubs."
When you are following the top-down methodology, you often encounter a situation where subroutine A calls (and hence depends on) subroutine B. Yet you want to write and test A before B is written.
For example, subroutine A might call subroutine B to find out whether a device is ready before trying to output to it. Subroutine B is absolutely vital to the finished program, but for purposes of writing and testing A you just write a "stub" version of B which doesn't actually talk to the device, but just says "the device is ready."
In this context, a stub is a piece of temporary scaffolding that is put in place solely to allow work to proceed, which is not a part of the finished product, and which must be removed and replaced with the real subroutine before the product is released.
I fantasize that it is a couple of years ago, and that there are enormous numbers of articles that anyone can see need to be written, and that I have decided to write about (say) echinoderms. As I start to write, say, an article on "Echinodermata," I realize that I will eventually want to write and link to Asteroidea, Echinoidea, etc. So I create stubs for these, with two things in mind. First, I have at least some intention of going back and actually writing those articles. Second, I know that there are other people who know as much or more than I do about echinoderms, and may prefer to write the article on Asteroidea myself rather than waiting for me to do it.
So the stub serves _three_ purposes: a reminder to everyone that there's an article that needs to be written, an implied statement that I sort of plan to write that article when I get around to it, and an implied invitation to others that if they feel like working on this _before_ I can get around to it, they should just jump in.
I notice that "The Perfect Stub" clearly presents stubs in the context of an intention by the creator of the stub to continue personally working on expanding the stub. It seems to suggest that the expected timeframe for this expansion is a few weeks; that is, it should reasonably expected that the stub contributor will keep nibbling away, adding small accretions to the stub, and that if a few weeks have elapsed and nobody else has taken on the job of writing the article the stub creator should assume that nobody else is going to, and they should write the article themselves.
Part and parcel of this viewpoint is that a stub is not useful in itself. As with the programmer's stub, it is just a temporary expedient to allow work to continue, and must be replaced with a real article before "release."
Does this imaginary view of mine correspond to an historically correct description of the mindset with which stubs were viewed a couple of years ago?
WikiEN-l mailing list WikiEN-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikien-l
_______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com
The expressed problem with stubs was that they show up as an article which has already been written, yet when you click on the blue link like to [[Tucson, Arizona]] all you get is "Tucson, Arizona is a large city in southern [[Arizona]]. It was felt to be misleading and a potential disappointment to users. It was felt that an empty link, which showed up in red rather than blue was better.
I always thought that was all nonsense.
Fred
From: dpbsmith@verizon.net Reply-To: English Wikipedia wikien-l@Wikipedia.org Date: Tue, 21 Sep 2004 15:04:19 -0500 To: wikien-l@Wikipedia.org Subject: [WikiEN-l] History of "stub" concept?
I have some guesses about the evolution of the "stub" concept on Wikipedia and am seeking information from oldtimers as to whether my guesses are right.
I first encountered the word "stub" in a technical context. About the time I started hearing about "top-down programming," which would have been, um, the 1980s, I also started hearing about "stubs."
When you are following the top-down methodology, you often encounter a situation where subroutine A calls (and hence depends on) subroutine B. Yet you want to write and test A before B is written.
For example, subroutine A might call subroutine B to find out whether a device is ready before trying to output to it. Subroutine B is absolutely vital to the finished program, but for purposes of writing and testing A you just write a "stub" version of B which doesn't actually talk to the device, but just says "the device is ready."
In this context, a stub is a piece of temporary scaffolding that is put in place solely to allow work to proceed, which is not a part of the finished product, and which must be removed and replaced with the real subroutine before the product is released.
I fantasize that it is a couple of years ago, and that there are enormous numbers of articles that anyone can see need to be written, and that I have decided to write about (say) echinoderms. As I start to write, say, an article on "Echinodermata," I realize that I will eventually want to write and link to Asteroidea, Echinoidea, etc. So I create stubs for these, with two things in mind. First, I have at least some intention of going back and actually writing those articles. Second, I know that there are other people who know as much or more than I do about echinoderms, and may prefer to write the article on Asteroidea myself rather than waiting for me to do it.
So the stub serves _three_ purposes: a reminder to everyone that there's an article that needs to be written, an implied statement that I sort of plan to write that article when I get around to it, and an implied invitation to others that if they feel like working on this _before_ I can get around to it, they should just jump in.
I notice that "The Perfect Stub" clearly presents stubs in the context of an intention by the creator of the stub to continue personally working on expanding the stub. It seems to suggest that the expected timeframe for this expansion is a few weeks; that is, it should reasonably expected that the stub contributor will keep nibbling away, adding small accretions to the stub, and that if a few weeks have elapsed and nobody else has taken on the job of writing the article the stub creator should assume that nobody else is going to, and they should write the article themselves.
Part and parcel of this viewpoint is that a stub is not useful in itself. As with the programmer's stub, it is just a temporary expedient to allow work to continue, and must be replaced with a real article before "release."
Does this imaginary view of mine correspond to an historically correct description of the mindset with which stubs were viewed a couple of years ago?
WikiEN-l mailing list WikiEN-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikien-l
I agree with you on that. One possible solution may be to colourize links to stub articles the same colour as links to articles that don't exist.
Richard
On Tue, 21 Sep 2004 14:55:53 -0600, Fred Bauder fredbaud@ctelco.net wrote:
The expressed problem with stubs was that they show up as an article which has already been written, yet when you click on the blue link like to [[Tucson, Arizona]] all you get is "Tucson, Arizona is a large city in southern [[Arizona]]. It was felt to be misleading and a potential disappointment to users. It was felt that an empty link, which showed up in red rather than blue was better.
I always thought that was all nonsense.
Fred
From: dpbsmith@verizon.net Reply-To: English Wikipedia wikien-l@Wikipedia.org Date: Tue, 21 Sep 2004 15:04:19 -0500 To: wikien-l@Wikipedia.org Subject: [WikiEN-l] History of "stub" concept?
I have some guesses about the evolution of the "stub" concept on Wikipedia and am seeking information from oldtimers as to whether my guesses are right.
I first encountered the word "stub" in a technical context. About the time I started hearing about "top-down programming," which would have been, um, the 1980s, I also started hearing about "stubs."
When you are following the top-down methodology, you often encounter a situation where subroutine A calls (and hence depends on) subroutine B. Yet you want to write and test A before B is written.
For example, subroutine A might call subroutine B to find out whether a device is ready before trying to output to it. Subroutine B is absolutely vital to the finished program, but for purposes of writing and testing A you just write a "stub" version of B which doesn't actually talk to the device, but just says "the device is ready."
In this context, a stub is a piece of temporary scaffolding that is put in place solely to allow work to proceed, which is not a part of the finished product, and which must be removed and replaced with the real subroutine before the product is released.
I fantasize that it is a couple of years ago, and that there are enormous numbers of articles that anyone can see need to be written, and that I have decided to write about (say) echinoderms. As I start to write, say, an article on "Echinodermata," I realize that I will eventually want to write and link to Asteroidea, Echinoidea, etc. So I create stubs for these, with two things in mind. First, I have at least some intention of going back and actually writing those articles. Second, I know that there are other people who know as much or more than I do about echinoderms, and may prefer to write the article on Asteroidea myself rather than waiting for me to do it.
So the stub serves _three_ purposes: a reminder to everyone that there's an article that needs to be written, an implied statement that I sort of plan to write that article when I get around to it, and an implied invitation to others that if they feel like working on this _before_ I can get around to it, they should just jump in.
I notice that "The Perfect Stub" clearly presents stubs in the context of an intention by the creator of the stub to continue personally working on expanding the stub. It seems to suggest that the expected timeframe for this expansion is a few weeks; that is, it should reasonably expected that the stub contributor will keep nibbling away, adding small accretions to the stub, and that if a few weeks have elapsed and nobody else has taken on the job of writing the article the stub creator should assume that nobody else is going to, and they should write the article themselves.
Part and parcel of this viewpoint is that a stub is not useful in itself. As with the programmer's stub, it is just a temporary expedient to allow work to continue, and must be replaced with a real article before "release."
Does this imaginary view of mine correspond to an historically correct description of the mindset with which stubs were viewed a couple of years ago?
WikiEN-l mailing list WikiEN-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@Wikipedia.org http://mail.wikipedia.org/mailman/listinfo/wikien-l
--- Richard Gould rwgould@gmail.com wrote:
I agree with you on that. One possible solution may be to colourize links to stub articles the same colour as links to articles that don't exist.
I would be careful about that. There are many articles that are marked as stubs that actually have good content, but they could be larger.
===== Chris Mahan 818.943.1850 cell chris_mahan@yahoo.com chris.mahan@gmail.com http://www.christophermahan.com/
__________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
Indeed. 'Stub' is not being used to refer to pages that are purely placeholders. It is also being used for articles that, while short and substantially incomplete, do inform. It's a marker that the information is not complete.
People tend to use the term 'substub' for 'little better than a blank article', but there is no universally agreed on template for that.
-Matt
On 22 Sep 2004, at 01:44, Matt Brown wrote:
People tend to use the term 'substub' for 'little better than a blank article', but there is no universally agreed on template for that.
-Matt
Actually, there ''is'' a template:
{{substub}}
However: There is ''quite a lot'' of dispute on what the template should say / whether it should exist / whether/when it should be used, etc. etc. So unless and until there is agreement on this issue, it's probably best ''not'' to use it. -- Use of the {{substub}} template currently is an open invitation for controversy.
-- ropers [[en:User:Ropers]] www.ropersonline.com