Return-Path: X-Original-To: apmail-incubator-allura-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-allura-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EC915D123 for ; Fri, 26 Oct 2012 17:50:57 +0000 (UTC) Received: (qmail 98584 invoked by uid 500); 26 Oct 2012 17:50:57 -0000 Delivered-To: apmail-incubator-allura-dev-archive@incubator.apache.org Received: (qmail 98555 invoked by uid 500); 26 Oct 2012 17:50:57 -0000 Mailing-List: contact allura-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: allura-dev@incubator.apache.org Delivered-To: mailing list allura-dev@incubator.apache.org Received: (qmail 98542 invoked by uid 99); 26 Oct 2012 17:50:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Oct 2012 17:50:57 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL,T_FRT_PROFILE2 X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 76.96.27.243 is neither permitted nor denied by domain of dave@brondsema.net) Received: from [76.96.27.243] (HELO qmta13.emeryville.ca.mail.comcast.net) (76.96.27.243) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 26 Oct 2012 17:50:51 +0000 Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta13.emeryville.ca.mail.comcast.net with comcast id FpJU1k0011u4NiLADtqV8k; Fri, 26 Oct 2012 17:50:29 +0000 Received: from b.local ([68.61.106.151]) by omta21.emeryville.ca.mail.comcast.net with comcast id FtqS1k0073G0l1w8htqTkF; Fri, 26 Oct 2012 17:50:28 +0000 Message-ID: <508ACD61.2000606@brondsema.net> Date: Fri, 26 Oct 2012 13:50:25 -0400 From: Dave Brondsema User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: allura-dev@incubator.apache.org Subject: Re: Allura new features References: <5085AB15.2030306@brondsema.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Yea, that all makes sense to me. Sounds like a good way forward. You may want to add a config option in production.ini, though, to control whether users are allowed to add new trove categories. Some sites may not want to allow regular users to add them; only the administrators. -Dave On 10/26/12 6:59 AM, Stefano Invernizzi wrote: > 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 > >> On Mon, Oct 22, 2012 at 10:22 PM, Dave Brondsema >> 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 : dave@brondsema.net >>> 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. >> >> > -- Dave Brondsema : dave@brondsema.net http://www.brondsema.net : personal http://www.splike.com : programming <><