DMB application announcement requirement

[basak]

Description

We have a couple of cases of DMB applicants not announcing their applications prior to the application meeting, which causes difficulty in our process since the mailing list archive also currently doubles as our application history archive, and then we cannot easily record the result or find it afterwards.

Examining the documentation, it looks like perhaps it might be being implied that the announcement is optional, so adjust the wording to make it clear that it is part of the process.

The DMB agreed on Monday that while we might want a different process for archiving applications and their outcomes, we don't have a process yet, so until we conclude the specifics of any replacement, we should keep the existing system so that we don't inadvertently end up with three by only half-doing some change now.

Checklist

• [N/A] I have read and followed the Ubuntu Project contributing guide
• [N/A] My pull request is linked to an existing issue (if applicable)
• [N/A] I have tested my changes, and they work as expected

[basak]

Sorry, the initial commit was bad, based on the wrong parent commit, and didn't include the actual change. I've forced pushed a fix to that now. But I think reviews have now been requested from the wrong people. After the force push it looks like the right people were then requested for review.

[basak]

@MitchellAugustin, @TheJJ, @kajiya3141, @ottok: FYI. Please announce your application to devel-permissions@ following this documentation so that we can process them properly.

I'd also appreciate your insight on how you missed the requirement to announce your application and what we might be able to do to improve the process to save the admin headache when this keeps happening.

Thanks!

[MitchellAugustin]

I'd also appreciate your insight on how you missed the requirement to announce your application and what we might be able to do to improve the process to save the admin headache when this keeps happening

Thanks @basak !

Speaking for myself, I think the change of verbiage that you propose here does help since the prior "you can announce" can be interpreted to sound like it is an optional step.

I also think it'd be good to include the full email address in this doc page (devel-permissions@lists.ubuntu.com, or devel-permissions [at] lists [dot] ubuntu [dot] com if we want to avoid bots).

One thing that I think could really guarantee that people don't miss it is if some bot account or similar method replies to Discourse DMB application posts with a reminder of this requirement. (I noticed that there seems to be some sort of similar crawling happening with this Ubuntu Weekly Newsletter draft that appears to have crawled my Call for Testing post yesterday, so maybe that's an option here too.)

[basak]

Thanks @MitchellAugustin. I don't think we have the resources to implement a bot unfortunately, but contributions welcome!

@ottok sorry, please disregard - I found that your application email was stuck in moderation and accepted it through.

[TheJJ]

Hey Robbie! I haven't announced yet since https://documentation.ubuntu.com/project/who-makes-ubuntu/developers/dmb-application/#application-process-overview (right above your patch from this pull) says that you should send the mail after having collected enough endorsements - which I have not yet :)
I've sent the mail now - thanks!

[basak]

@TheJJ thank you! That explains it. I propose to adjust the process then to avoid that hole - see commit. Thanks!

[TheJJ]

sounds great already!
how about using the order "prepare application - select spot - send mail - maybe collect more endorsements - have meeting"?
then people don't have to guess what's enough, instead the process continues without some arbitrary waiting on endorsements.
what do you think?

[cpaelzer]

then people don't have to guess what's enough, instead the process continues without some arbitrary waiting on endorsements. what do you think?

We have to decide which order we want, do we:

a) want an early announcement, to allow others who worked with them to chime in or so. In that case it would be "prepare application -> select spot -> send mail to announce -> collect endorsements". Hereby the pressure is on the applicant if they truly get the endorsers together and we can only prepeare and evaluate once it is the DMB meeting day as before not all endorsements might be complete.

b) want the announcement to be done when all is ready, that is what currently is in this PR "prepare application -> collect endorsements -> select spot -> send mail to announce". In this case spots are not taken so much in advance and when announced on the ML an application is meant to be mostly ready. This one further avoids anyone arriving to the meeting to then say "yeah but sorry I thought I'm complete today but I'm not" wasting a meeting slot.

I'm in favor of (b) as it was proposed.

@basak could you please rebase this to the latest so it can be merged?
Furthermore while reviewing this I realized this still thinks in wiki-terms with "Create your space" and then "Prepare application form". That is no more the way in Discourse and rarely did in recent years people create a wiki space with all applications underneath. If I change this in another PR now we conflict, but could you please consider to 1. Take away "If you already have a page, you can reuse it." and take away all of "Prepare application form" because that is already outlined in the section below that the link in "Create your space" links to. Then rename "Create your space" to "Create your application" (as it is two in one now).