Hi, We know about the “trove category” mechanism to categorize projects. However, project categories and skills are not exactly the same thing. For example, a user may specify skills in using a specific library, or he/she may want to specify non-technical skills like requirements analysis, and so on. At the same time, “trove category” also includes items related to licenses or intended audience of the project, which are not strictly related to user skills (a user may know the legal details of a license, but the name of a license is probably not what a user would generally include in his/her skills list).
Nonetheless, matching user skills and projects would be a great feature for the forge. Maybe we could use the predefined trove categories as a starting set for skills, allowing to add new items to this collection since, as Dave said, a flexible system is best. But should the “skills” collection and the “trove_category” collection be the same one, or should we have two separate collections, initializing the skills one so that, in the beginning, it includes all the items in trove_categories related to user skills? In that second case, the match would be harder. For that reason, we think that the best solution is to use the trove_category collection, allowing users to choose only among those sub-hierarchies related to skills (programming language, topic, operating system, database environment, user interface and translation). Therefore, they will not see the remaining items (development status, license and intended audience) when they are entering their skills. Users will also be allowed to add items in the trove_category collection. For example, they could add a new programming language or a new database management system, and the same new element would be available to be chosen in the admin section of a project. Let us know if this is a good solution. Stefano Invernizzi and Simone Gatti 2012/10/23 Roberto Galoppini <[email protected]> > On Mon, Oct 22, 2012 at 10:22 PM, Dave Brondsema <[email protected]> > wrote: > > Hi Stefano and Simone, > > > > I've replied with some feedback on the merge request itself: > > https://sourceforge.net/p/allura/git/merge-requests/7/#aa21 I hope > that we can > > get into a better rhythm and give you feedback more quickly in the > future. > > > > Regarding how to add skills, I think a flexible system is best, so that > users > > aren't restricted by slow admins who haven't added certain skills into > the > > system yet. Maybe it could be completely freeform so that users can > enter > > whatever they want? Of course, if that's the case, we wouldn't want an > enormous > > drop-down list of millions of items. Maybe a "tagging" approach where > the most > > frequently used skills are at the top of the suggestion lists. > > > > As another point of reference, the old classic SourceForge account pages > > have/had a way for users to record their skills. The choices were based > on the > > categories (aka "trove") used for categorizing projects. Here's a tiny > > screenshot: http://screencast.com/t/2srkALf5n1h This could be cool > since it'd > > potentially let users and projects be matched together, e.g. within a > Help > > Wanted system. > > It makes sense to me. > > Talking about Trove it's worth to mention that since we distributed it > under a CC license others have started the creation of a multilingual > dictionary to categorise software. Below you find the original article > at the JoinUp site, it includes a pointer to the live google doc > already containing a Dutch, French, Italian and Spanish translation. > > > https://joinup.ec.europa.eu/asset/adms_foss/document/help-us-give-software-taxonomies-multilingual-labels-represented-skos > > Roberto > > > This approach could work within Allura too. The "TroveCategory" > > model already exists and is used for project categorization. Of course, > this is > > a completely different direction than my "tagging" suggestion, since it > uses a > > fixed list :) > > > > -Dave > > > > On 10/4/12 8:51 AM, Stefano Invernizzi wrote: > >> Dear all, > >> > >> We would like to extend Allura by offering functions to increase > awareness > >> of people and organizations working within the forge. > >> > >> In a previous message on this mailing list we briefly described the > goal of > >> our work and got positive feedback. > >> Now we would like to detail our proposal to understand if it can become > >> part of the main distribution of Allura. > >> > >> As a first step, we would like to allow users to provide more details > about > >> themselves, so that everybody can have a better knowledge on someone > else's > >> skills and, as a consequence, on their potential contribution on a > certain > >> project. To this end we have already developed a prof-of-concept that > you > >> can find here: > >> > http://sourceforge.net/u/stefanoinve/allura/ci/83168501e8d8711e875335a2843f005b509edf25/tree/ > , > >> for which we have submitted a merge request a few days ago. > >> > >> In our prototype the page which allows users to set their preferences > >> includes more details that are then stores as part of the users' > personal > >> data. These data are shown to others in the profile included in the > project > >> associated to a user. > >> More in detail, the data include > >> > >> * Gender > >> * Birth date > >> * Country of residence > >> * City of residence > >> * Timezone > >> * List of social networks (for the moment, Facebook, Linkedin, Google+ > and > >> Twitter are listed as predefined and fixed possible choices) > >> * List of personal websites (or pages about the user) > >> * List of telephone numbers > >> * Skype account > >> * A list of time slots in which the user is available, namely when > he/she > >> is usually working on the forge and can easily reply to inquiries. These > >> time slots are required to be expressed according to the timezone of the > >> user who is visualizing the information. > >> * A list of periods during which the user will be inactive (for example, > >> for holidays, or other relevant commitments). > >> > >> Of course, all these data are completely optional, and everybody can > freely > >> decide not to provide any additional detail, for obvious privacy > reasons. > >> Additionally, users can insert their skills. This can be done through a > >> form, linked to the one used to insert personal data. Skills are shown > >> together with the remaining personal data in the profile of the user, > >> included in his or her personal project. Particularly, each user can > insert > >> a list of skills, selecting them from a predefined list of categories. > They > >> can also add a level of proficiency on each skill (three levels are > >> allowed: low, medium, high) and an optional description (for example, to > >> describe what experience he/she had with a certain skill). > >> At the moment, users are not allowed to create new kinds of skills, they > >> can only use the existing ones. However, we are wondering if this is a > good > >> choice or not: probably, a user should be allowed to do so, because new > >> technologies are introduced everyday, therefore a predefined list could > be > >> a problem. We will immediately start working on this issue. We will also > >> consider existing classifications for skills like the one offered by > Dice. > >> As we discussed in our first message, we would also like to introduce > the > >> concept of organization, so that each user will be allowed to make > explicit > >> his/her enrollment in an organization, and we are going to implement a > tool > >> to retrieve statistics about the contibution of a user to all the > projects > >> hosted on the forge. We will provide more details on this very soon, but > >> first of all we would like to get a feedback on the first part of our > work > >> and on the possibility of merging its evolution in the main Allura > >> repository. > >> > >> Thank you, > >> Stefano Invernizzi and Simone Gatti > >> > > > > > > > > -- > > Dave Brondsema : [email protected] > > http://www.brondsema.net : personal > > http://www.splike.com : programming > > <>< > > -- > ==== > This e- mail message is intended only for the named recipient(s) above. It > may contain confidential and privileged information. If you are not the > intended recipient you are hereby notified that any dissemination, > distribution or copying of this e-mail and any attachment(s) is strictly > prohibited. If you have received this e-mail in error, please immediately > notify the sender by replying to this e-mail and delete the message and any > attachment(s) from your system. Thank you. > >
