Request - Formal procedures for introducing new projects to the DC-Vault

[Accs]

Moderators - If this thread is unacceptable in this forum, please inform me (email) and remove it.

I would like to know what the formal procedures are for:
Adding a new project to the DC-Vault. There are some general guidelines in the the DC-Vault FAQ (http://www.team-ninja.com/vbulletin/showthread.php?t=36977), but these are VERY general, and I think they could stand to be cleaned up a bit. Archiving a completed project from the DC-Vault. Removing a non-compliant project from the DC-Vault.If there are no formal procedures for these, I would like to request that such procedures be created. Finally, I would like to open a path where the users can request changed to the above procedures, for the improvement of the process.

The reason for this request is that I have seen a number of anomolies in some of the recently added projects, that I don't believe should be there. I believe that these anomolies are contrary to the long-term goals of the DC-Vault.

For those making suggestions, please be CONSTRUCTIVE. A comment of "xxx sucks" would be inappropriate. Comments of "xxx could be made better by ...", or "I think we need to improve xxx" would probably be acceptable.

[russkris]

I dont think I quite understand what you want.. Maybe if you could start by offering some suggestions..

A project can be added to the Vault once it meets the guide laid out in the FAQ

[umccullough]

Oblig. Disclaimer: I'm not an administrator or decision maker for DC Vault, just a lowly team "captain" of sorts.

I think having some additional qualifications for projects acceptable for the Vault would be a good idea.

There's clearly been a large upswing in the number of DC projects in the last year or two (mostly BOINC) - which presents a challenge. It's hard to determine the quality of a project, it's administration, or the results without some amount of careful scrutiny and/or a review period. I think there should be some additional parameters around plentiful work queues, total project scope and estimate time to completion (it may not be worth it to bring <12 month projects into the Vault).

I sorta like the idea of "archiving" projects - or optionally viewing team positions including all archived projects... but I'm not sure if it really meets the goals of The Vault. Right now they appear to simply be removed - probably because they fail to meet one of the criteria (such as no longer allowing registration).

However...

I get the impression that DC Vault is not just a stats aggregator, but rather a continual challenge that keeps the competitive teams involved with the newer, smaller projects rather than concentrating on domination of the longer running, larger ones. This means the removal of "extinct" projects entirely sort of makes more sense.

For the smaller teams (like Team Haiku), it can be somewhat challenging to figure out the best way to allocate our resources across ALL of the Vault projects in order to get the best "bang for the buck" on Vault ranking... which isn't necessarily a bad thing. We don't have the advantage of being around since the "beginning of time" when there were just a few projects worth crunching for. It's even worse when those projects are gone, dead, or no longer provide work.

So, back to the procedures for removing projects from the vault:

What exactly ARE the thresholds that a project must pass before they qualify for removal? I can remember some projects that sat dormant on the Vault forever before they got removed.

[Accs]

I dont think I quite understand what you want.. Maybe if you could start by offering some suggestions..You have official criteria (somewhat loose, but official criteria nonetheless) for adding a project to the DC-Vault. I'm interested in seeing similar criteria for archiving/removing a completed project, and for removing a project if it becomes, or is found to be, non-compliant with the admittance criteria.A project can be added to the Vault once it meets the guide laid out in the FAQI'm not sure that the guidelines in the FAQ are adequate. Examples of this are as follows: APS@home - This project has had little work since it was put into the DC-Vault. I don't know where the problem is, but either the Vault participants ripped through the work faster than expected, or the project is unable to provide work on a reasonable basis. In either case, it's currently borderline on the "active" part of it's requirement (from the FAQ). I believe that a "Beta" period should exist, where it is in the vault, and scored, but the scores are not counted. This will: Let the teams know that the project is soon to be placed into the DC-Vault Allow the teams to debug the project on a large scale Allow the teams to report problems with the project to the project manager, and/or the DC-Vault, as appropriate Allow the teams to manage their resources to handle the additional project Yoyo@home - This is basicly a BOINC project wrapper for non-BOINC projects. All work completed on yoyo@home goes to a single "yoyo@home" account in the projects that it front-ends. This work does NOT credit your work/points or even the Team, in the project being run. The issue here is that someone owns that account, and they could easily add it to a team, creating a HUGE bump in their team's standings in the projects. A BOINC wrapper for a non-BOINC project is fine. Not having that wrapper forward CORRECT information on the user completing the work to the non-BOINC project is potentially bad, and should be adequate reason to exclude the project from the DC-Vault. Using the project's "anonymous" account would be fine, if there was a way to verify that it wasn't changed (either deliberately or by accident). Radio Network Design - This was (is?) on a list of possible projects to be added to the DC-Vault. It appears to me that this is a project whose primary beneficiary is the Mobile Phone Service Providers, in that it reduces their cost to achieve a given level of coverage. I consider this to be a commercial project with the financial gain limited to a VERY few (the previously mentioned providers). Because of this, I don't think it should be eligable to be included as a DC-Vault project. MoneyBee is different in that anyone who works on the project has access to the same information.

In addition, as previously stated, there are NO official criteria for archiving/removing a project when it’s complete, nor is there any such criterion for removing a project that becomes, or is found to be, in violation of the acceptance criteria.

[Accs]

It's been over three days, and no response of any sort has been provided to either umccullough or myself. No "good idea", no "we'll look into it", no "waiting for more input", not even a "we don't like it, get lost". Is there any chance of making this a two-way exchange?

The initial response from russkris indicated that an open discussion was possible, but a discussion requires responses. Is anyone listening?

[Nanobot]

We have been waiting for more feedback from the general community but this has not happened.

The rules for adding projects is already documented and any active project which no longer adheres to these rules will be removed. If you think the rules should be changed then a new thread should be started to discuss proposed changes laying down your proposed changes.

As for archiving, there is no plan to introduce this as I do not have the time to think about the design or implications of it at the moment.

Any project which is available to the public which meets the criteria for inclusion will be accepted. We are not going to start policing the worth of a project e.g. Radio Network Design as that would cause untold discussion as to what was a worthwhile project. If individuals or teams do not want to participate in a project then that is fine but we will not exclude any project which does not meet the project inclusion rules. This includes projects issuing old work as teams can get credit for processing those units.

The yoyo problem you mention can be adressed by posting a thread asking us to look into a team where you think this has happened after you have checked the teams project participation. If we feel this is an issue we can always remove the project from that team.

umccullough mentioned the problem of the small teams so I will give a little hint here; why do we list the number of Vault teams participating in a project on the Projects page :D

Personal note here, not as a Vault admin or Team Ninja admin, the use of formal procedure in the thread title causes a slight concern as once formal procedures are introduced you usually need a large team of people to police those procedures, over 20 years of IT experience has taught me this. So I do not think that formal procedures will be introduced into the Vault which is just a bit of fun

And finally [groans of thank goodness from the reading populace] the reason we had a period of inactive projects not being removed was that we were all busy and then I needed to update the system so that projects could be temporarily removed.

Remember

Rule 1 have fun

Rule 2 see rule 1

:)

[cswchan]

Remember

Rule 1 have fun

Rule 2 see rule 1

:)

Very well put Nano...

:cool:

[Accs]

We have been waiting for more feedback from the general community but this has not happened.And the community has been waiting to see if this turned into a discussion. The tone of your response has shut that path down. So much for being willing to accept suggestions.

[Da-Grizz]

Ni !

This discussion SHOULD continue - ACCS and UMCCULLOUGH have some VERY valid points , and I agree with most if not all of them .
Yes one point is to have fun in the stats , but not at the expense of blindly crunching for points in dubious projects , and some projects are dubious , tapping into the Boinc community for their own gain .
Most serious "Crunchers" are able to review and make up their own minds if a project is worthwhile , but many cannot and look to concepts such as the DC Vault for guidance . Inclusion of a project in the Vault constitutes such guidance whether you agree or not . Look at the mad scramble for points in the recently included projects in the Vault to see what I mean . As such it caries responsibility , and maybe the inclusion rules need to be revised ?
For example , state whether a project is indeed a disguised private venture , (in your opinion) designed to harvest the cycles of the DC community (and they ARE out there) for their own (fiscal) gain .

Off of soap box now , and please do not construe this missive as a negative against DC Vault , I assure it is not , your Vault has done wonders in getting people to contribute their CPU cycles (for free) in worthwhile projects .

Set up a proper discussion forea , and let people know what projects you are considering for inclusion on a proactive baseis , not the fait-acomple as at present . Maybe some of us will give you a lot more feed-back then , and shut up moaning :eek::duck:

Best Regs KWSN Da-Grizz

[russkris]

Set up a proper discussion forea , and let people know what projects you are considering for inclusion on a proactive baseis , not the fait-acomple as at present . Maybe some of us will give you a lot more feed-back then , and shut up moaning

Thats a great idea, but what I use to do is post in the new project forum and ask people to give me feedback about each project, but I very rarely got any info back, and it turns out the same people would reply time and time again..

This is why we are taken back by the sudden interest in the Vaults rules...

I wish we had people like yourself helping with the project inclusion threads..

Please feel free to write your own and post it everyone can read and input more or less

[umccullough]

I think we can still keep the discussion moving in a positive direction :)

I got from Nanobot that he's not interested in setting up any method of tracking "Archived Projects". To be clear, I wasn't exactly for or against the idea of Archived Projects myself - in fact, I find them to be a problem for newer teams to overcome (Free-DC's DCR system is a good example of this problem).

As for making the rules for project inclusion more stringent - I think russkris is correct: Not enough people get involved.

Even if no hard rules are set, I'd like to see the Vault start scrutinizing the following before adding new projects:

* "Solid" project administration
* Plentiful work queue
* Estimated time to complete project, and whether work will be available after that
* and to some degree: Usefulness of the project

I think these can't be necessarily quantified in all cases, but if those questions are at least asked, and vault participants can attempt to provide some reasonable answers to those questions (possibly by asking the project admins themselves) - it might help the rest of us determine the worthiness of the project.

The final point above may or may not serious impact whether the project gets accepted into the vault, but if the project's acceptance is teetering - the project's usefulness could help with a final decision. There are clearly some projects out there of questionable usefulness, fortunately few, if any, have graced the Vault's project list yet ;)

If a project aims to provide personal financial gain for the project admins - it would be nice to know that before inclusion into the vault. However, it's the responsibility of persons who have this information to come forward and mention it so that it can be investigated further.

[Accs]

we are taken back by the sudden interest in the Vaults rulesIt's not a sudden interest. I've seen projects with various issues come and go in the vault, and mostly the problems weren't enough to trigger a response. The YoYo project nudged me to the point where I felt that I had to ask the above questions.

To clarify, when I wrote "official", I meant nothing more than a set of qualifications, similar to the qualifications you have for vaulting a project. It appears that your qualifications for removing a project are the same.

Additionally, I said "archival", meaning that the project would be considered to be completed, and would be removed from scoring. It would be nice to keep a copy of the final project scores, but that's not necessary.

I'd still like to see a few modifications to the vaulting requirements.

[russkris]

Ok... I see your points, and all of them...

The reason to keep the rules as general as they are, is so that basically every project has a chance of being added..

There is going to be no archiving of projects in the Vault.. Pure and simple, it a game, a bit of fun.. Or else it will turn in to another stats site and there are plenty of them..

As to projects like yoyo@home, well plain and simple, wrapper projects are totally new to me and I have not read much about them. But what I understand is yoyo gets the points in the project it has wrapped eg: DNET.. then a user crunching for yoyo@home gets BOINC points..

So given that, yoyo at home wouldn't be create a DC-Vault team, that would be just un-fair

[Accs]

There is going to be no archiving of projects in the Vault.. Pure and simple, it a game, a bit of fun.. Or else it will turn in to another stats site and there are plenty of them..OK.As to projects like yoyo@home, well plain and simple, wrapper projects are totally new to me and I have not read much about them. But what I understand is yoyo gets the points in the project it has wrapped eg: DNET.. then a user crunching for yoyo@home gets BOINC points..

So given that, yoyo at home wouldn't be create a DC-Vault team, that would be just un-fairThat's one of the problems with yoyo. The points go to a specific "user" account. There exists the possibility for that user account to be joined to a team. The DC-Vault isn't in charge of the user, and probably wouldn't want to be.

Perhaps an additional set of rules for "BOINC wrapper" projects is needed. One of these rules might be that the wrapper place the points into the project's "anonymous" account.

Another might be that a BOINC project not be part of a BOINC wrapper. It makes no sense to go through two BOINC layers. Am I missing something here?

Personally, I don't see a reason for ANY wrapper project to be in the vault. Creating a BOINC wrapper for a non-BOINC project is fine, but placing it into the vault as a separate project? NO. If the wrapper passes the user information to the wrapped project, then everything works correctly, without the additional overhead of another project.

Not allowing wrapper projects in also significantly reduces the risk of abuse (one of my problems with yoyo). I'm not saying that this abuse will occur (in fact, I doubt it will), but it IS a risk, and it's a risk that you don't have to take.

Finally, when a "dumb" wrapper is used, the underlying project shows points for the wrapper. The user/team that performed the work isn't given ANY credit on the project web page. Of course, if the team receives vault points for the wrapper project, they shouldn't also receive vault points for the wrapped project.

The point here is: Make the wrapper project smart. Don't vault the smart wrapper. Let the user/team receive credit in the base project. The user/team will now receive BOINC points for their work. Ok... I see your points, and all of them...Any feedback on the possibility of a 2-4 week "Beta" period for new projects? I listed several of the benefits previously.The reason to keep the rules as general as they are, is so that basically every project has a chance of being added..Just because a project exists, doesn't mean that it should be in the vault. First, there are the issues with the wrapper projects. Before a wrapper project is considered, I believe that the underlying project(s) need to be looked at. I believe that it's MUCH better to give credit for the user/team on the actual project, than to give credit for the wrapper.

Second, as you wrote previously, "Pure and simple, it a game, a bit of fun". When purely commercial projects (like Radio Network Design) enter the vault, I believe that it ceases to be a game.

[russkris]

Second, as you wrote previously, "Pure and simple, it a game, a bit of fun". When purely commercial projects (like Radio Network Design) enter the vault, I believe that it ceases to be a game.

How is not a game if Radio Network Design enters the Vault... Please explain..


I think the from now on, when I or someone else posts about a project, I would like to see everyone contribute to the thread, including yourself, it seems you know far more then I about Distributed Computing then me..

I cant see the rules changing.. But I can see the discussion increasing prior to a projects addition... And on the same wave-length, when a project is to be taken out the same process should be adopted..

As far as yoyo@home goes, there was no comment about the things you are concerned about.
http://www.team-ninja.com/vbulletin/showthread.php?t=42194

[Accs]

Second, as you wrote previously, "Pure and simple, it a game, a bit of fun". When purely commercial projects (like Radio Network Design) enter the vault, I believe that it ceases to be a game.How is not a game if Radio Network Design enters the Vault... Please explain..It's like playing cards. As soon as somebody throws money on the table, it moves from being done for fun to being done for profit. Radio Network Design is actually worse than that, because it's for someone else's profit.

It can be argued that many of the Bio projects are done to create better drugs, which a pharmacutical company will market, and make a profit on, but there's a WORLD of difference between helping to create drugs to improve people's quality of life, and decreasing the number of transcievers that a mobile phone provider needs by 5%.I think the from now on, when I or someone else posts about a project, I would like to see everyone contribute to the thread, including yourself, it seems you know far more then I about Distributed Computing then me.I doubt that I know more about DC than you. I may know more about computer security, accountability and risk identification than you.

One of the other advantages of the previously requested Beta period (project listed in the vault, possibly with a score, but not added into the totals) is that it will have more global visibility than a thread on your forum. When a new project appears in Beta, if the teams know that they still have time to comment on it, you'll get more feedback (good and bad).I cant see the rules changing.. But I can see the discussion increasing prior to a projects addition... And on the same wave-length, when a project is to be taken out the same process should be adopted..

As far as yoyo@home goes, there was no comment about the things you are concerned about.
http://www.team-ninja.com/vbulletin/showthread.php?t=42194I didn't see the thread. This is the first time I've been to this forum in almost a year. It's that visibility thing again.

[mgpower0]

simple fact is yoyo is part of a team "rechenkraft" and it has been stated that points from his yoyo@home team will not be directed to rechenkraft. Until this changes (if/when) it changes I can see no reason to remove the project from the vault. yoyo@home incorporating evolution and OGR has no less merit as a project than a LOT of the others included in the vault

[KAMCOBILL]

Hi All,

I'm a little confused about the Problem with the Yoyo @ Home Project. It is running D2OL project http://www.d2ol.com/ and it seems to me this is a good project. OR not?

Here ar my Stats at Yoyo @ Home: http://www.rechenkraft.net/yoyo/show_user.php?userid=89

Here are our Team Stats: http://www.rechenkraft.net/yoyo/team_display.php?teamid=22

Here are All team Stats: http://www.rechenkraft.net/yoyo/top_teams.php?sort_by=total_credit&offset=0

Here are All User Stats: http://www.rechenkraft.net/yoyo/top_users.php?sort_by=total_credit

Now the only difference I can see is that Yoyo @ Home has a team at the D2OL Project which anybody that is running Yoyo @ Home is a member. Since I'm running D2OL project too, I'm kind of competing against our team. But, There is no way I could do as much work for D2OL running their client as I can with BOINC Manager.

Also Riesel Seive is similar to Yoyo @ Home. they have their own client and BOINC Project.

Just wondering what the problem is.

Bill

[mgpower0]

D2OL??? as far as I know yoyo@home runs OGR and evolution@home on the boinc platform. OGR has a project in the vault which is standalone (doesn't use boinc) our OGR results from yoyo@home go to a user with the name yoyo@home in the standalone project. People are worried that this username will be joined to a team at OGR an that team will get all credits from the boinc project. As stated in my post above, yoyo himself is part of the rechenkraft team and has said his yoyo@home user name at OGR will not be credited to this or any other team. So no I don't see any problem with yoyo@home being in the Vault. It is one of the more stable projects out there and I think a fellow crunching enthusiast should be congratulated for developing his own project. If the credit does go to a certain team at ORG in the future then sure, remove yoyo@home from the Vault. Projects are added and removed all the time, no need to do it while yoyo sticks to his/her word

[umccullough]

If the credit does go to a certain team at ORG in the future then sure, remove yoyo@home from the Vault. Projects are added and removed all the time, no need to do it while yoyo sticks to his/her word

And likewise, remove that team's rank from the non-BOINC OGR on the vault as well... after all, they wouldn't have gained the OGR rank without everyone's contribution to yoyo@home...

This is what I believe was the scenario being portrayed, and the concern being voiced.

I doubt it will happen that way, the public outcry against that team, and the bad name they would have earned as a result would likely prevent it.

[KAMCOBILL]

I'm didn't mean to type in D2OL. I'm meant to type in ORG25. What was I thinking. :o :scratch: Sorry about that. No wonder I could find the links. :D

I can see a concern in a way. I found the links now to ORG25:

Team: http://stats.distributed.net/team/tlist.php?project_id=25&low=1&limit=100

User: http://stats.distributed.net/participant/plist.php?project_id=25&low=1&limit=100

The User and Team has the same name. If User yoyo @ home BOINC Wrapper would change teams we would be crunching with BOINC for new team, almost like we are now. Unless he joins our Team :D . But, would the credits go with the User. Most Projects don't transfer the credits. I've never changed teams before so I don't know which projects that do transfer credits.

Thanks for the help in understanding why it could be a problem. But, I don't think yoyo would do that.

Bill

[IronBits]

YoYo@Home is an account, not a Project, and as such, should never be listed in the DCR.
However, he has done a wonderful job providing a Boinc wrapper for non Boinc projects.
Only Projects should be listed.
For example, DNET is a PROJECT, and YoYo@Home is a user account in the DNET project...

In the case for Teams, YoYo@home could possibly be listed as a Team, but, all the user accounts are anonymous, so that doesn't wash either.
my .02 cents.

[umccullough]

Fair suggestion - but let me also remind you that that "PrimeGrid" is a user under SoB Sieve and PSP Sieve (and possibly others).

This is not a new issue.

[Beyond (Ars)]

Brief comments:

First of all, thanks again for all the hard work you put in to make the Vault possible!

One of these rules might be that the wrapper place the points into the project's anonymous account. I like this idea and it should be easy for the project administrator to dump the wrapper results into anonymous. This would go a long way towards preventing abuse of wrapper projects by their creators. Also, how is it fair to the other project users to compete against such a behemoth as everyone contained by the wrapper?

I also would like to see blatantly commercial projects kept out of the Vault. What's to keep those who financially benefit from lobbying for inclusion and thus gain from the huge increase in participation that goes along with being a Vault project?

On another subject:
One specific project I'd like to address: APS has had VERY very WUs available since it's inclusion. There have been no new WUs available since around October 20, 2007 (I've had two machines constantly polling for them). The project admin has made several promises for WUs by certain dates. None of those promises have been kept. The project admin has been totally AWOL for 44 days when he posted the following:

It's taking longer than I thought to recompile all the applications. More before Christmas. ;-)

As someone asked in the forum, Which Christmas?
Anyway, I think you might want to consider dumping this one.

Thanks for listening!
Beyond

P.S. And I totally agree, lets all have fun with this, it's a game.

[Accs]

as far as I know yoyo@home runs OGR and evolution@home on the boinc platform. OGR has a project in the vault which is standalone (doesn't use boinc) our OGR results from yoyo@home go to a user with the name yoyo@home in the standalone project. People are worried that this username will be joined to a team at OGR an that team will get all credits from the boinc project. As stated in my post above, yoyo himself is part of the rechenkraft team and has said his yoyo@home user name at OGR will not be credited to this or any other team. So no I don't see any problem with yoyo@home being in the Vault.Then you appear to have either a very limited imagination, or absolutely no understanding of what "risk" is. The "risk" portion of the problem with yoyo@home is three-fold. It's possible for the owner of the yoyo@home account to intentionally change the team membership. I don't believe this to be a major risk. It's possible for the owner of the yoyo@home account to accidentally change the team membership. I believe that this is also a minor risk, but slightly greater than the above risk. Finally, it's possible for someone to brute-force the password, and change the team membership. This is the greatest of the three risks. While this risk also exists with normal user accounts, the contributor is the one who sets the password, and would be the only one to lose. In the case of yoyo@home, the "project manager" sets the password, but all the yoyo@home contributors would stand to lose.Use of the project's "anonymous" account completely removes both the second and third of these risks. The first risk will continue as long as there's a 3rd-party BOINC wrapper for the project.

QUESTION: Who runs the BOINC wrapper for Riesel Sieve?

Another issue with yoyo@home is that the "project user/team" competes with REAL users and teams in OGR. Has the scoring code for the OGR project been modified to exclude the yoyo@home team from the points computations?

The above comments address the OGR portion of yoyo@home.

Yoyo@home also runs the evolution@home project. This is a project that can have long-running work-units (user adjustable), and uses email to notify the project of completed work (sorry, I had previously thought it was a BOINC project). This is similar to some of the prime-number projects, and could benefit from a BOINC wrapper. On the other hand, it would benefit even more by having a native BOINC interface. If the project doesn't want the assistance, who are we to force it on them? If they DO want the assistance, I'm sure Lliane would be willing to help them with it. I'd feel much better about this BOINC wrapper if it were run by the actual project.This is not a new issue.So we ignore it instead of solving it? I believe that it would be useful for the long-term health of the DC-Vault to establish specific criteria and limits WRT wrapper projects.

Yoyo@home has no real reason to exist. As shown above, it has several issues that need to be addressed, by the author, the evolution@home project administrators, and (I think) by DC-Vault. IMHO, it's not worth keeping/fixing, as there are better solutions.


The item that continues to be missing from this thread is interaction from the DC-Vault administrators. Not a peep out of them for over a week.

[Fireblade]

The item that continues to be missing from this thread is interaction from the DC-Vault administrators. Not a peep out of them for over a week.

That doesn't mean they're ignoring the thread.

You must bare in mind, that the DC Vault administrators have both full-time jobs, and families!
As such... the DC Vault is something they can only manage to maintain, in whatever spare time they might have.
So don't be so ready to criticize their absence/lack of comment!

I'm quite sure, if/when they manage to find the time to visit the forums... read this thread... and subsequently feel the need to comment... they will do so ;)

[Nanobot]

The current rules for the inclusion of a project are:
Project eligibility is governed by the following guidelines:

The project must:

be active
accept new members and teams immediately upon registration
have parsable team stats
have team stats that are updated regularly
provide a client program which runs on a local PCThe project must not:

be a keylogger or mouseclick counter
have a maximum number of teams or membersRag
If you wish us to consider adding wrapper projects into the "project must not" category then the best thing would be to start a new thread with a title something like "Exclude Wrapper Projects From The Vault" (for improved visibility) and add a poll (http://www.team-ninja.com/vbulletin/faq.php?faq=vb_read_and_post#faq_vb_poll_explain) so the general feeling of the Vault community can be determined. If the majority feel as you do then we can change the rules.


One specific project I'd like to address: APS has had VERY very WUs available since it's inclusion. There have been no new WUs available since around October 20, 2007 (I've had two machines constantly polling for them). The project admin has made several promises for WUs by certain dates. None of those promises have been kept. The project admin has been totally AWOL for 44 days when he posted the following:

It's taking longer than I thought to recompile all the applications. More before Christmas. ;-)

As someone asked in the forum, Which Christmas?
Anyway, I think you might want to consider dumping this one.

It is easy to temporarily remove a project from the Vault when it no longer adheres to the inclusion rule, as APS clearly does not because it is not active. I will ask Rusty to start a project removal thread.

[Accs]

If you wish us to consider adding wrapper projects into the "project must not" category then the best thing would be to start a new thread with a title something like "Exclude Wrapper Projects From The Vault" (for improved visibility) and add a poll (http://www.team-ninja.com/vbulletin/faq.php?faq=vb_read_and_post#faq_vb_poll_explain) so the general feeling of the Vault community can be determined. If the majority feel as you do then we can change the rules.I need some time to work on the proper wording, but I'll put one up when ready.

I was hoping for some more feedback.

[Accs]

If you wish us to consider adding wrapper projects into the "project must not" category then the best thing would be to start a new thread with a title something like "Exclude Wrapper Projects From The Vault" (for improved visibility) and add a poll so the general feeling of the Vault community can be determined. If the majority feel as you do then we can change the rules.I need some time to work on the proper wording, but I'll put one up when ready.

I was hoping for some more feedback.I have come up with an initial set of rule suggestions, and have started a thread on the Ars Technica forum requesting comments on them. That thread is:

http://episteme.arstechnica.com/eve/forums/a/tpc/f/122097561/m/516008400931

When that thread is complete, I'll post the finalized versions in a new thread here, with polls, for the community to vote on.

[umccullough]

I don't have an account on the Ars forums (and I'm too lazy to register), therefore hopefully you won't mind if I comment here instead:

#1 makes absolute sense to me... in fact I'd even say anyone attempting to wrap a BOINC project is probably up to no good :P

You may want to define "Anonymous" for #2 - for example the PrimeGrid account is anonymous by most definitions in that it's not specific to any person working on PrimeGrid, but rather to the wrapper project itself.

I might also suggest that your concerns about having the account hacked on the parent project isn't really a problem (your primary reasoning for #2). It would only be a temporary problem at most I suspect - once the wrapper project admin contacts the parent project and explains that his account has been hacked, I have to assume the parent project's admins will correct the issue - and possibly even lock the account from it happening again.

I think the rule should be more loose - such that the team/user that is granted points on the parent project CANNOT also participate as/on a DC-Vault team. This "punishes" the team rather than the project.

I believe #2 and #3 should be an "OR"... If a project has created their own BOINC wrapper, I can't see any requirement that points be accumulated as "Anonymous"... Once they have full control over both projects (#3), there should be no worry of the points getting credited incorrectly right?

#4 is a larger problem than simply wrapper projects... Although I suspect wrapper projects could cause this to get out of hand a lot quicker.

Any BOINC project could run any number of applications that may or may not be related to each other. Maybe DC-V could separate "Misc" into a couple categories - one being "Combined Projects" or something.

Anyhow, that is just my feedback :)

[Accs]

I don't have an account on the Ars forums (and I'm too lazy to register), therefore hopefully you won't mind if I comment here insteadNot at all. Feedback is good.You may want to define "Anonymous" for #2.It is the account to which points go in a project if no account is specified. It is the PROJECT anonymous account, not just an account in the project that happens to receive the input from many users.

The reason for this particular account is that the project code is usually set up to not allow changes to this account.I might also suggest that your concerns about having the account hacked on the parent project isn't really a problem (your primary reasoning for #2). It would only be a temporary problem at most I suspect - once the wrapper project admin contacts the parent project and explains that his account has been hacked, I have to assume the parent project's admins will correct the issue - and possibly even lock the account from it happening again.I agree that it would probably only be a temporary issue, but it's a completely unnecessary one.

But it's more than that. There's also the issue that the non-BOINC teams in the underlying project will have this HUGE team (the wrapper project team) that competes against them. This looks bad, and requires the DC-Vault admins to add code to extract that project team before the points are computed. I don't believe that the project anonymous accounts are in a team, nor can they be.I think the rule should be more loose - such that the team/user that is granted points on the parent project CANNOT also participate as/on a DC-Vault team.I don't think it would work as well, especially on the larger teams.I believe #2 and #3 should be an "OR".I think it simplifies the ruleset slightly. It also makes it easier for the vault administrators to verify. Finally, it's something that they can point to and say "All the other projects do it, your does too, if you want it in the vault". By minimizing the number of special cases that need to be considered, you simplify the life of the administrator, and you end up with fewer arguments from wanabe projects. The only special case in the four suggested rules is #3. Rule #4 isn't a special case; it's just that you're guaranteed that the wrapped projects will all be in the same group, when there's only one wrapped project.#4 is a larger problem than simply wrapper projects... Although I suspect wrapper projects could cause this to get out of hand a lot quicker.TTBOMK, this has only come up in wrappers.Any BOINC project could run any number of applications that may or may not be related to each other.Could you please point me to one? Perhaps Rule #4 should be generalized. Could you provide alternate (more general) wording?

[umccullough]

Any BOINC project could run any number of applications that may or may not be related to each other.

Could you please point me to one? Perhaps Rule #4 should be generalized. Could you provide alternate (more general) wording?

Well, many of the BOINC projects have multiple applications - most related to each other or at least in the same category - but there's no requirement that it be this way.

Just go to their project page and click the "Applications" link to find out how many they are using.

I believe Leiden allows other people to develop applications and get them approved. It appears they're all mostly "Physical Science" based currently, but that could possibly change.

WCG even appears to have a new AfricanClimate project - which would be a probably different category than their usual medical/biological projects. I don't know much about it otherwise. This would be a primary example of what could happen regarding categorization. I therefore think it's a poor decision to limit a project's participation based on whether the science spills into multiple categories or not.

Even now, if you were to take the vague categorization of projects from DC-Vault and break it down any further - you'd very likely start running into conflicts.

I'm not sure I really understand the exact purpose of this rule you're suggesting - other than another way to specifically exclude yoyo@home and projects like it in the future. I think it's clear that distributed computing technology could be used for any number of purposes, and a project could take on multiple problems covering various categories if they have the resources to do so.

What if something like Travelling Salesman Project (which I would categorize as a mathematical issue) were to be maybe used for some type of physical science or medical research next? Would it be immediately excluded by your rule?

[Accs]

I'm not sure I really understand the exact purpose of this rule you're suggestingSeveral good points here. An update was posted in the Ars Technica forum here (http://episteme.arstechnica.com/eve/forums?a=tpc&s=50009562&f=122097561&m=516008400931&r=279004700931#279004700931).

[umccullough]

Several good points here. An update was posted in the Ars Technica forum here (http://episteme.arstechnica.com/eve/forums?a=tpc&s=50009562&f=122097561&m=516008400931&r=279004700931#279004700931).

Thanks for cross-posting my comments :)

Anyhow, I'll wait a bit and see how the discussion unfolds on the Ars forum now.

[russkris]

I have temporarily stickied this thread...

[jbbdude]

Speaking of TSP, will that be added to the Vault? I see no reason why not.
It is an honorable endeavor.

[fractal]

Much as I too dislike unnecessary procedure, I respectfully propose the following rule for both project additions and removals:

- A one week last call will be posted before any project addition and removal. This will be a probationary period. Any project scheduled for removal for no work will have the removal canceled if work starts flowing. Any project scheduled for addition will not be added if no work is flowing during the probationary period.

APS was added to the vault just as it ran out of work with the only points to be had were reissued work. There is still no work in that project. It does seem an honorable endeavor as well.

TSP was just added to the vault just as it too ran out of work with the only points to be had are reissued work. I have no reason to believe they won't work through their teething issues, but being vaulted sure seems to be a kiss of death for projects of late.

[KAMCOBILL]

Hi All,

Predictor @ Home bacically been out of work since August and has just started up again Team Stats (http://www.xgrubberskickass.com/php/Teams/Predictor@Home.php) . It's still in the Vault. What I can't figure out is why any projects that are reachable is removed. Every project, at least every BOINC Projects has run out of work, been down or has been unreachable at times. Like BURP, for instance, it was removed from the Vault Team Stats (http://www.xgrubberskickass.com/php/Teams/BURP.php) . Yet it has plenty of work now.

As long as the rules are met other than work, why don't they remain in the untill they say there are done (e.g. Project Nueron (http://neuron.mine.nu/neuron/) or XtermLab (http://neuron.mine.nu/neuron/) ) and not because there's no work. Sometimes they says they are down and not, like Seasonal Attributes, but I'm still getting work form them. Can't figure that one out.


Just a different view.

Bill

Edited: Proteins @ Home had been out of work from July to February Team Stats (http://www.xgrubberskickass.com/php/Teams/Protein@Home.php).

[DigiK-oz]

Having worked my way through the entire thread, I would like to voice my opnion.

The wrapper/yoyo issue : I think buiding a wrapper around non-Boinc projects is a great idea, BUT the credits should be given in the wrapped project, not a seperate project for the wrapper. I have no idea how hard this would be to implement in the wrapper, though. As it is, most of my teammates (Dutch Power Cows) are very reluctant to participate in yoyo, since yoyo might overtake is in the wrapped projects, and we don't like to be overtaken :) Sort of shooting your own foot.

As for the addition/removal : Since we just recently got interested in our vault-ranking, we are rather low-ranked on several projects. Some of them supply no work, making it impossible for us to gain points there. I know projects can be added/removed, but this always leads to discussion, mainly because the wording in the FAQ is so general. Specifically on the issue of having work available, I would suggest a specific "grace period" of a month or so. Any project which is suggested for addition, gets a "candidate" status (provided it meets the other requirements). If it supplies plenty of work during it's candidate period, it gets included. Similarly, if a projects is suggested for removal, one look at the stats of the project during the previous period will tell whether it should be removed or not. Of course, any removed project can become a candidate for addition if work starts flowing again.

This would make it clear to anyone when a project will be added/removed. Of course, addition or removal is always a disadvantage to some terams, and an advantage to others (depending on the vault-ranking in the specific project). By setting a period like this, it would be clear (and fair) addition/removal.

Having said all this, a big thumbs up to the vault for making distributed computing a little more challenging/interesting.

[yoyo]

Hello,
I just found this thread and want to say something to my yoyo@home goals and principles.

The main goal of the yoyo@home wrapper is to bring the Boincies to none-boinc projects and with this increase the computing power for the none-boinc projects. Therefore it is important to have the credits in the Boinc world, in yoyo@home Boinc project, boincstats.com, boincsynergy.com and in all credit comparison pages where boinc teams are compete with others. I also wish to have yoyo@home in DC-Vault. Most Boinc users are not looking into the none-boinc project team stats, even do not have a team there.

The second point is, that a team which crunches via yoyo@home should not get credits twice, in the Boinc world and the none-boinc project.

I'm also aware, that other teams/users are feeling the risk, that all credits of the Boincies can go to a specific team on the none-boinc project to which they compete. Therefore the boinc accounts in the none-boinc project assigned to one wrapper team. With this it is in most projects not possible to move existing credits to new teams. Nearly in all projects credits which are in a team account can't be moved to an different team. All requests to credit a yoyo@home Boinc account to the none-boinc user account for this user are rejected by me. There were already discussions to do it in the forum of muon, in irc with dnet and with the author of evo.

Additionally I and the Boincies want to see how big the power of the Boincies is in the none-boinc project, compared to the power of the none-boinc part. E.g. in evo the Boincies provided up to now more than 50% of all computing power.

yoyo

[The Shadow]

So ALL Wrapper Non-Boinc projects could go to the Misc Section on DC Vault (YoYo), and points to the teams in the YoYo project only? That would seem fair .

Can/could that work ?

It would be interesting as per your thoughtful comparison .

Shads

[umccullough]

So ALL Wrapper Non-Boinc projects could go to the Misc Section on DC Vault (YoYo), and points to the teams in the YoYo project only? That would seem fair .

You would have to clarify what a "wrapper" project is specifically, since I believe there are several BOINC projects now using a "wrapper" in order to run a non-boinc client that was developed solely by them.

This would also include PrimeGrid which is crunching purely math projects via wrapper (mostly sieve and LLR). It would have also included RieselSieve BOINC (if they were still running), and a few others which I don't have on the top of my head ATM.

That is, unless you classify this as purely 3rd party wrapper projects (yoyo for example seems to be run by Rechenkraft, not by the respective projects it wraps). But even then, PrimeGrid crunches as a third party for several prime-related projects as well...

It's a pretty gray/grey area :)