incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <>
Subject Re: Allura new features
Date Fri, 26 Oct 2012 17:50:25 GMT
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.


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:
>>>  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:  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.
>> 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:
>> ,
>>>> 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 :
>>> : personal
>>> : 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 : : personal : programming

View raw message