On Tue, Jul 5, 2016 at 10:15 AM, leif <not.rea...@online.de> wrote: > Dima Pasechnik wrote: >> On Tuesday, July 5, 2016 at 3:32:09 PM UTC+1, vdelecroix wrote: >> >> On 05/07/16 10:25, Dima Pasechnik wrote: >> > 1) well, there are always more tickets to work on than humanely >> possible to >> > handle quickly. >> > It would be good to know which tickets are more urgent than others >> from the >> > community point of view. >> >> If only trac users are allowed to vote, I do not see the point of this >> popularity contest. If everybody was allowed to vote, we would at least >> have an idea of user needs. >> >> >> the problem is that it is easy to abuse. >> Somebody goes and votes on a ticket 100 times, just for "fun". >> >> >> Moreover, I am not sure any developer would actually care about the >> votes. How would you ensure that highly popular tickets are worked >> on/reviewed in priority? >> >> Well, we certainly have an substantial anarchist element present here >> :-), but given that >> there are people paid to work on Sage... > > Yes, let's vote which work /they/ have to do! :P > > >> > 2) WP7 >> >> What does it mean? >> >> https://github.com/OpenDreamKit/OpenDreamKit/issues/149 > > Ah, Funding-SPAM! > > > "We will survey the data needed to assess development models of > large-scale academic open-source projects, such as the probable > correlation between the size of the atomic contribution vs. the speed of > the contribution making it into the code [ROFL!], and collect > appropriate statistical data, to be published as a report (and possibly > a conference publication) D7.1. > The latter will require non-trivial amount of programming work, even > only for ***the test system, SAGE***."
This is the first I've heard of this, and I have to say +1. I'm for using rigorous quantitative and testable approaches to trying to improve the quality and efficiency of software development instead of naive intuition and imagining that we are already optimal at what we do. Thanks to whoever is doing this tedious project. -- William > > [...] > > "Open source projects tend to be fragile, in the community sense, and > suffer from disagreements that ultimately result in “forks” and the > resulting duplication of effort. We will analyse this phenomenon in the > framework of algorithmic game theory, and try to design finely tuned > systems of incentives and rewards for contribution so as to increase the > stability of the community and its useful output. > > We will focus on three areas: > (1) prioritisation of bug fixes and feature requests to achieve > reliable and useful systems; > (2) effective cooperation among multiple collaborative projects; and > (3) making decisions about the strategic direction of the system. > > We will use prioritisation as a testbed for designing incentives that > encourage all participants to contribute towards sustained development > of the most important parts of the system [Important to whom?]. To this > end, we will use ideas from the burgeoning field of mechanism design > [26] and in particular recent research on crowdsourcing in algorithmic > mechanism design [34]. While doing so, ***we will apply outcomes to a > case study system — SAGE***. > The reason why prioritisation poses a challenge in the development of > open-source academic software is that this process is task-driven: > typically, tasks (also known as tickets) are posted on a website, and > their priorities are set in an ad hoc manner. This model is usually good > enough for simple bug fixing, but for more elaborate tasks it often > leads to unacceptable delays. We will apply preference and opinion > aggregation techniques [3] to develop a community prioritisation scheme > for bugs and feature requests (which may rely on a reputation scores > technique, such as one used on MathOverflow), and implement this scheme > as a TRAC [39] add-on D7.2. As SAGE is using the TRAC server [2], this > will be easy to test on our testbed system." > > > So we all become experimentees... > > > -leif > > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
