Apache Allura™

If we wanted to integrate with openhatch.org, we would need to implement a bug tracker importer for them that used our allura APIs. Info at https://openhatch.org/wiki/Bug_tracker_import_code/adding_a_bug_tracker and https://openhatch.org/wiki/Bug_tracker_import_code/architecture

I talked with 'paulproteus' on #openhatch on Freenode, about the possibility of some kind of interaction between SF and OH. He'd like for us to have a better interop before we start telling projects about the site.

From conversation on the #openhatch IRC channel:

[14:51] <paulproteus> It'd be good for us to write an implementation of a crawler for the Allura backend before we do any big announcement, then, since that's an obvious thing people will want.
[14:52] <paulproteus> If you want, you folks could modify the Allura bug tracker interface to have a standard for marking bugs as "good for newcomers"
[14:52] <paulproteus> And then OpenHatch could query an API on your end that let us see which projects had any bugs with that tag set, in which case those bugs could show up on openhatch.org automatically, without user intervention.</paulproteus></paulproteus></paulproteus>

Does this seem like something we could pursue from our end?

See also [#2660]

• labels: --> p3

• labels: p3 --> p3, for-community

• labels: p3, for-community --> p3, for-community, helpwanted

Thank you for reporting Rich

An Apache project called Help Wanted! was announced in 2016. Discussion about that project make it clear that helpwanted.apache.org was not just focused on solving issues. Recruitment was an important goal. Perhaps because recruitment is non-trivial, helpwanted.apache.org was abandoned years ago (lists.apache.org).

Rewards

As this ticket shares origins with helpwanted.apache.org, recruitment is probably its main goal. However, if we focus on the challenge of matching tasks to potential workers, the priority for each worker is their rewards divided by their costs.

This ticket's body already treats most of the elements influencing costs (language and task mastery), although supervision/assistance from existing volunteers is another important one. What is more neglected is the rewards side. In CBPP, bounties are on average a very small part of rewards, and rewards for the same accomplishment vary a great deal for different workers/volunteers. Some of the greatest incentives are the intrinsic hedonic rewards and the value of a solution to a certain worker (or the organization they serve).

This personal value―and the interest one finds in a task―largely depends on the project’s goals. For example, I contribute(d) to several Apache projects, but I have no interest in most. At my age, I have very little interest in contributing to games. But I am highly interested in communication, science, knowledge, governance, contributor experience, productivity and quality, and I get way more hedonic reward when contributing to projects which improve these, such as Apache Allura, than to games.

Similarly, someone serving a music corporation will have more interest in audio compression, streaming and mixing projects.

So, while categorizing software is non-trivial, I think an efficient mapping relies on tracking how much interest each worker has in different types of software.

A large part of the interest in a task is also to develop the necessary skills. This represents a difficulty: if I am asked for my skills, I may say I know C and master PHP, but these are not languages I wish to develop. I would much rather work on Java, Kotlin, Python or C# projects, even though I am far from proficient in these.

🅭🄍