[General Topics] nathanchance:
I've had to think about this topic quite a bit, not only as The Flash, forum moderator but as Nathan, friend of several awesome developers and amateur "developer" myself. These questions are hard to answer because there are two sides to every argument but I'm going to do my best. I'll start by talking about some of the things that I've seen as issues in the past and work from there.

What is development?

Something that has really been bothering me over the past several months is what people around me define as development. We always want to foster development but that involves having an accurate description of what development is. Many people think development involves building ROMs, kernels, and apps and putting them out to the world. I would say this is partially true. Development is really contributing and moving something forward (i.e. taking a ROM, kernel, or app and either creating it from the ground up or taking an existing product and changing something about that in a significant way). We can argue semantics about what significant means in this context but the bottom line is that something has to change. Repo syncing and building from source is NOT development. It just isn't. It takes a total of three commands (simplified) to build AOSP from source:

. build/envsetup.sh
lunch
make otapackage

I have even made a guide on setting up an environment and building from source, I could teach my grandparents to do it. That is not development to me and it should not be fostered as such. Sharing a straight repo sync build is sharing someone's work without their permission and it's not moving anything forward, it's just doing what has already been done. If a user is trying to change things and make something their own, a developer would have a hard time making the case for that work not to be shared because it's been modified, provide credits are given and authorship be maintained. I think a developer should still be able to say they don't want works to be based on theirs but at the same time, true development should be fostered. There is a difference between squashing competition (which some people seem to think is what a developer is doing when preventing repo sync build from being shared) and preserving the integrity of one's work. We want to encourage people making a difference, not sharing something that has already been made.

But the Apache License!!

Oh yes, I've heard this argument before. "The Apache License doesn't prevent you from sharing the work, it is allowed!" Well if that's the case, why does XDA block works of known kangers? There are several ROMs that are prevented from being shared here, aren't we violating the license in that case? I don't personally think so. Furthermore, if this becomes an issue of logistics, ROM developers are allowed to set their own terms:

ROM developers can place further restrictions because their initial distribution is compliant with AOSP's Apache 2.0 license. If that's what it takes for developers to control their release cycle, so be it.

Unofficial vs. official builds

I would argue that most developers don't have an issue with unofficial device ports (in fact, developers are generally happy when people share their work with more people). However, XDA treats official and unofficial device builds the same. Let's say a developer allows an unofficial device build to be posted (i.e. gives permission for sharing the work under rule 12). Under the current rules, this means that if someone were to post a build of an official device that they built, they could share it without any repercussions (assuming they say credits to XYZ ROM). I think almost every developer you talk to would tell you that's wrong. Developers release their work when it feels ready. Yes it is open source, that's the beauty of Android but a work is not complete without the approval of its creator and XDA should honor that. Some people will say it doesn't matter but that is how you lose developers and cause people to close up their source. Official devices should be given special protection without care for unofficial builds. This is a problem with the way people interpret "work" within the context of rule 12. It could be interpreted as a single commit or feature (which I think is how it may have been intended initially to my knowledge) but it has grown to encompass entire ROMs and kernels. Since a ROM developer allowed an unofficial device port, it means they allowed their whole work to be shared thus making it fair game for everyone. I don't think this is how it should be, we have seen entire ROMs pull out of XDA for this very reason. If a "work" in the context of a ROM was defined as a single device build, ROM developers could hold exclusivity over their official devices and still allow unofficial device builds without issues. However, I personally don't like rule 12 as it stands, I think it can be slimmed down and reworked but this is how it could be fixed in the meantime.

Donations...

If I had to pinpoint a single issue with the Android development scene in general, it would be donations. Because rather than people getting together to collaborate and make something great, there is division and a ton of competition to see who can get the best thing out the quickest so users donate to them first. It's also an issue of appearances. I won't name names but I know a lot of developers who are constant working on stuff in the background so they don't have a ton of time to make a lot of appearances in the threads but they are the ones who are keeping development going. Yet, because there may be someone who may be pulling a lot of those commits in their own ROM and releasing it before the other person and since users don't look at Github or any source code, they think that person is the one doing all the work and donate to them. Users don't care as long as they get the bacon so to speak. If it were up to me, I wouldn't allow donations at all because people can't be responsible with it. This is a great hobby to be a part of, it's sad to see some people who glory seek for personal gain. If donations HAVE to stick around, the donation button should be the only place that donations should be requested. No signature messages, no thread messages, nothing. Donations are supposed to be discreet in my opinion, having a message saying "Donations are appreciated but not required" is still adding some sort of obligation, like nudging a person and pointing them to a tip jar. Yes, it's not required but it makes it way more upfront.

To actually answer the proposed questions...

- Should developers be able to moderate their own threads?

Like others have said, I think opening and closing threads should be a power given to developers. As for actual moderation like removing posts or editing... I would give the developers the benefit of the doubt and allow them to do so. HOWEVER, guidelines would need to be established about what developers are and are not allowed to remove. It would alleviate stress on moderators. There would have to be supervision but that could be accomplished by having users report abuse of moderation. This would be no different from developers establishing Google+ communities. Most are responsible enough to know only remove disrespectful comments and leave legitimate posts intact.

- How should moderators deal with "annoying" users? What should they do when individual developers don't think we're doing enough to control a problem?

It depends. If the user is just asking a ton of questions, I think the developer should just ignore them. If they are harassing the developer or being entitled, I'd happily remove the posts and scold the user. Entitlement is a huge issue in this scene because users feel they are owed something, when they aren't. A big complaint I have heard from other developers is that moderators don't appear consistent or send mixed signals (I can't speak to the credibility of this because I don't think I do this and I don't know what others do). BUT, if this is true, I think the rules need to be clarified and moderators should always be in touch with developers regarding issues. I think Developer Relations is a good first step but I'd like to see something like a developers panel that not only advocates for developers in trying situations but keep the moderators in touch with the developers base. I think there has been a rift there for a bit, a mismatch so to speak and it'd be nice to see it mended in some way.

- Should we allow donation requests? In what form?

Answered above.

- Should we require a developer to get permission before using another developer's work? What happens when one developer is unhappy about the use of his work by another developer?

I think permission should always be sought for a work, regardless of how big or small. It's a sign of respect. Maybe not for something as small as certain commits as it is kind of understood that once it is on Github, it's fair game but for full repos, permission should be sought. If a developer is upset, they should always reach out to the other developer first. A lot of disagreements are settled when talking to the person "face to face" because they can both air their grievances. I do understand why there is an exclusivity clause of rule 12 and I do think that needs to remain around in some shape or form because selective sharing is harmful when it comes to features or commits. I think every situation needs to be taken case by case in instances like this. It's hard to make a blanket rule for things like this because there is so much that goes into developments.

- What if Dev 2 made some small tweaks to the code?

It depends on the small tweaks. If it is string changes and refractoring, no, I don't think this should be allowed. It's not development because it isn't moving anything forward.

- What if Dev 2 made some big tweaks?

Assuming permissions, credits, and authorship are intact, there is no issue.

- What if Dev 2 acted as if the code was his and aggressively solicited donations?

Should not be allowed. No permissions or credits.

- What if Dev 2 gave proper credit, but still solicited donations?

I still don't think this should be allowed. Goes back to not development.

- What if Dev 2 posted buggy, in-process code that Dev 1 wasn't ready to release?

Depends. If it is within the ROM of dev 1 (let's say cherry-picked WIP commit, builds and releases), then no, should not be allowed. If it is within dev 2's ROM, as long as it is understood that dev 1 has nothing to do with it, I think that is fine. It's up to dev 2 to deal with bug reports and complaints.

- What if Dev 2 changed the name of the ROM?

I think this falls into the "small tweaks" category as it is just string changes. Should not be allowed.

- What if Dev 1 has previously given verbal permission but now wants to revoke that permission?

The only way I see this being okay is if developer 1 significantly changes their code, making it into a whole new work. Once permission is granted, it should not be revoked except extreme circumstances (logistics would determine what "extreme" means).

I am very happy that this thread has been made. I am thrilled to see input from others and I hope that this site continues to evolve and mature. It saddens me that the site has the name "Developers" in the title yet there are so many who do not like being here. Something needs to change because this is a great hobby and scene to be a part of.