DROP issue queue

I think its the same premise as this http://drupal.org/project/drupal_dojo

This is being used very much like the GHOP contest did and DROP is a Drupal continuation of that.

Yeah, there's more background discussion on this at http://groups.drupal.org/google-highly-open-participation-contest-ghop. Specifically, the threads that mention "post" GHOP.

There will be a front-page post forthcoming probably next week when GHOP officially ends.

I was looking at the project type list... Could something be added to that to cover these? Unfortunately nothing is coming to mind so it's not a terribly useful suggestion, I guess, but if someone could think of a good term... :)

Michelle

Please read the threads about the group and how it will be set up. All issues will be put here on d.o to be worked on within the community, which is why this project was created (as a catchall for tasks that don't fall under an existing project.) The exterior website is to track the tasks in terms of continuing the "contest" atmosphere (i.e. who has done how many tasks, etc.) which d.o nor g.d.o are equipped to do nor do we feel it appropriate to ask those sites to supply the necessary infrastructure for that.

FWIW, I think it's unfortunate to use a project for this, and would oppose a new project type to handle these sorts of catchall projects. The real solution is to add other ways to classify/tag issues, as per http://drupal.org/node/187480. I can't believe there are tasks that can't be classified under an existing project, and I think it makes the most sense for the project itself on an issue to match where the effort should be going. The point is to tag issues (regardless of the project they're for) as belonging to the DROP effort, and to setup a view of all DROP issues across all projects.

Here is my 2 cents.

For GHOP and perhaps for DROP, I think it is OK, since a discussion has happened, and an exception is made.

GHOP is not a normal project with defined code, but rather a set of tasks, so it is OK in that sense.

However, we don't want to make that a rule, because I can forsee freeloaders using d.o to advertise software that is not in the repository, and use the project module features for bug tracking and feature requests.

This has not happened yet, so we can defer the discussion till it does, or be proactive and prohibit this as a rule. If you use d.o, then everything should be on d.o, not offsite.

Please understand - this is not about code being off d.o!

The code and all issues, community interaction and patches will be here on d.o. The idea is to add a DROP category for issues so they can be tracked, regardless of issue queue. The *only* thing on the other site is a way to track points for people who do tasks in the issue queue so they can get "rewards" like a front-page post on d.o. Unless you want to install userpoints module on d.o this is really the best way for them to do that.

GHOP used the regular project issue queues and DROP will too. This project was created only for oddball issues that may not fall under a specific project's issue queue. We had a few of those in GHOP and so the idea came up. I actually wasn't part of this decision process for DROP, just relaying my understanding from what I have read elsewhere. Either way I don't have a big issue with this existing, on the other hand I do think that it will be lightly used and so could probably just go away if it is freaking people out.

@add1sun, "yes, but..." this is another step along the path towards people hosting code off of d.o

Notice how in the very first comment a previous and similar use becomes part of the precedent for doing this again. Note that in the case of the dojo there is plenty of code that is not on d.o (the theme is the most obvious example but I believe there are other custom drupaldojo.com specific modules as well).

I don't have a specific problem with this, especially because the people who are interested in running it 1) have a good purpose that clearly benefits d.o and 2) are frequently the people who have to tactfully explain to newbs "sorry, you can't do X because of rule12 and I know that Y breaks rule12 but it's an exception"

@dww:
"I can't believe there are tasks that can't be classified under an existing project"

It's very rare, indeed. Some examples where we had to do this during GHOP include:

• GHOP #97: Add PHP documentation to FAQ and Avatar (spans multiple modules)
• GHOP #74: Write a wrapper module for the Google Chart API (requires creation of a new module, and so a project for this does not yet exist).

There are other issues in the GHOP queue that should probably be moved over the the Documentation queue instead (presentations, cheat-sheets, commercials, etc.) but since the GHOP contest ends in less than a week, there's little point in re-categorizing these now.

In all other cases, the appropriate project queue for the given task is used.

While comment_alter_taxonomy will be a huge Godsend, it doesn't /quite/ get us there, because we still need a "mother" project to house these kind of odd-ball tasks. Further, it's very time-sensitive to get this infrastructure in place /now/ so that we don't lose the momentum the GHOP program has currently given us. We want to keep these folks engaged and keep giving them stuff to do.

@everyone else:
I would really appreciate it if people who are nay-saying in this thread would please read the referenced threads where we already hashed all of this out. There is no off-site code, there is no "forking" of Drupal efforts, there is nothing of the sort. For all intents and purposes, these are just plain old ordinary Drupal issues, only someone's probably more likely to step up to get them done.

I fully agree. These DROP nodes are always normal issues, so they can be recategorized or retagged later, there is no harm done. The current infrastructure allows people to grab momentum for DROP right now.

BTW I am guilty of the actual accusations of hosting code elsewhere and having a project for it on Drupal.org, which benefited Drupal 6 after all, so our use case would be a better poster child of what not to do unless you are extremely sure what are you doing. Let DROP move along :)

@webchick, thanks for the reply. My take on your specifics:

- #97 should be 2 issues then, 1 for each queue, both marked with the "GHOP" term, and both with "GHOP #97" in the title.

- Hrm, new modules, hehe, good point. ;) There was talk of a "module ideas" project at one point, right? Not sure it's worth it. However, it seems silly to have a GHOP project for new modules to add b/c of GHOP, and a DROP project for new modules to add b/c of DROP, etc. Seems like a catch-all "Module ideas" project would be a better solution for everyone.

- Right, the Documentation queue would have been better than the GHOP queue, since people who follow documentation efforts would have been more likely to find the issues and be able to help review/mentor.

Either way, I agree it's silly to reclassify now, as GHOP (at least this instance of it) is ending. I'm just talking about the general case here, and how we should deal with these issues in the long term, especially as relates to DROP.

@greggles, there is no offsite code involved with DROP or GHOP and I don't see it as a step in that direction. Yes, Dojo has code for the dd.com website but the Dojo is not using the d.o issue queue for the purpose of issue tracking for that code. The Dojo queue is really more about a Dojo task list for the group since g.d.o is really not suitable for that. We do have "feature requests" for the website redesign but those are just for planning discussion and will not extend to the actual work/implementation. They will be closed once the new website spec is written.

I can see that it is a bit fuzzy though and I have to say that I was not involved in the decision to start a queue for this on d.o but it is done now and so I use the tools that others in the community have provided. I have the feeling that the decision came from a) a desire to have a clean task list for the group and b) encourage more of a "working the community way" for the Dojo in general.

So, again, I'll just say that I have no great feelings one way or the other on this so if the community decided to get rid of the Dojo, GHOP and DROP projects it would be inconvenient but not something I'm gonna freak out about. If a decision like that were to happen though, perhaps the community needs to investigate ways to have task list/issue trackers for groups/projects that don't really have a codebase. G.d.o is fine for discussion but it is a far cry from the organization of an issue tracker and honestly I prefer to have one place where all of my Drupal "issues" can be listed and tracked easily.