Within Phase I, provider (consultant/company) identification will be conducted in a passive manner. That is, rather than the using a proactive identification of consultants based upon a delivered contract description from sales, we will institute the filtering of responses from postings to multiple read-only mailing lists. We will post contract descriptions to these lists as category appropriate, and then filter responses to find the best matching contractor based upon criteria defined in SGB Rules and procedures 2-1 Provider selection criteria.

There will be subject based, OS and language specific lists (e/g/ Perl, C, C++, Python, Java, Linux, Unix, Systems Administration, etc.). Needed lists will be determined by filtering the skillsets which we have received from interested consultants. Lists will be added based upon feedback and comments from future consultants, and from the contract descriptions which are received from sales.

All lists will be read-only, i.e. subscribers will not be able to post messages to them. There will also be an announcements list which will be subscribed to by all, where all announcements of added lists will be made. Interested members will also have the ability to subscribe to the Services Government Body list, to provide feedback, and ask questions.

We will require a page on the Free Software Consortium site which will list all listservs available. The users/consultants of the system will then be able to administer their settings, subscribing and unsubscribing from any/all lists.

The updated list of lists is available at fsc-sgb-lists.

The procedure for selection in Phase I is as follows:

SGB will get contract description from FSC Sales Government Body.

SGB will review, assign a position ID, and send email to appropriate list.

SGB will receive and review responses.

SGB will manually choose consultant(s) for position.

About Implementation Phase II

Phase II will involve design and creation of a skillset matrix, a web-based application for member consultants to enter their skillsets, and an application/utility to extract best matches for a given contract description. The skillsets will be stored into a skills matrix as described by Valdemar W.Setzer and Alexandre Freire [see the article Data, Information, Knowledge and Competency which more fully describes the competency skillset matrix idea and its possibilities here]. I am in active discussions with Alexandre Freire about the possible design of the matrix to best handle the intricacies of our needs within the FSC. There is no planned date for the switch to Phase II, rather, the move will happen when needs dictate, that is, when the number of contracts proves too great for FSC-SGB members to process manually.

SGB Specific Implementation Notes and Comments on Seltzer's Skillset Matrix Paper

I hope to soon reprint the article with full annotation inline (but only when given proper permission).

Sect. 1 -- The ideas: 1.1. I personally disagree with some of the semantics used within the paper, notwithstanding use within much earlier literature. That is, I would much rather invent a pure and concise term than try to get the world to correct usage fully ingrained even if falsely so ingrained. That said, I do understand the need of specific, definable, and separate terms within your work. We would likely require the use of descriptive language for each categorization of experience level. That is, we would possibly like to defer differentiation to the experts, and leave the user with clear and simple descriptions of the level of info/knowledge/competency, etc. You have already likely done something near this, and perhaps could offer insight. I make this point, because we will be extracting data from widely disparate sources (all around the world), and will be unable to formally train those entering the data.

1.2. I feel that in computer science, one can jump easily from your defined info level on to competency level without really working through a knowledge level. That is, I have often obtained info level from a book read, and never really obtain knowledge level separately from competency, as I develop knowledge quite as a result of acquiring competence.

1.3. I consider optional data structure as a level between your data and your info. That is, storage of data in a certain structure lends more value to that data -- value that a machine can use (even though it might not reach the level of your info). A machine can do things seemingly intelligently with data stored in an intelligent structure. Perhaps not unlike a dog or horse...?

1.4. I further believe that structure is part of the key to many other areas within this discussion. It is in fact possible that, say, humans and other animals store data structurally within the brain. This could explain the genetic passing of archetypal memory or instinct, as genes can code for the physical structure of the brain. They cannot code for dynamic personal memories. This might be a bit beyond the scope, but worth looking into.

1.5. Neural networks are another example of structural data storage. They can be used to recognize patterns, and more. They can also be tied together to add more value to the data stored.

1.6. Another possible level, recognition of competency. That is, it would be more valuable to be able to demonstrate that one's competency is recognized, by say a universal standards body, or common knowledge. Such that Larry Wall's competency in Perl is greater than mine.

1.7. When speaking of the "leveling of the criteria", might one normalize the data from an individual interviewer, or cross reference certain interviews as convenient, in order to use other statistical methods for normalization of all of that interviewers particular interviews.

1.8. A very important point for our use at the FSC, is a point not mentioned. A high or even moderate matrix score in a large number of areas would point to a good designer/leader, as that individual would not be predisposed to code or design an application in the language in which that individual has expertise. That is, one that is expert in language or ability: too often sees everything as problem: . Whereas, one that has multiple languages (say: or ) under the belt might be able to see the or problem that actually exists. I would like to use many filters such as this to pull out the data that we get.

Sect 2. -- Points among those which we might like to work with or add to the mix:

2.1. possibly add recognition of competency.

2.2. use of descriptive language rather than defined concise info/knowledge/competency for terms on forms for our use (will likely be web-based HTML forms).

2.3. a combination of the score levels of competency/experience listed in your paper.

2.4. possible changes/additions in score normalization/leveling esp. as listed above.

2.5. any needed changes to enable filtering of non-specializers such as under item #8 above (though I doubt any specific changes would be needed).