Skip to content
This repository has been archived by the owner on Apr 22, 2021. It is now read-only.

Disconnect our processes from a dependency on Google Season of Docs #45

Open
camerons opened this issue Aug 29, 2020 · 5 comments
Open
Labels

Comments

@camerons
Copy link
Member

The proposed proposal-selection.md is tied in a few places to Google Season of Docs. Feedback suggests we should break this tie.

This task is to investigate and find alternative processes which break the dependency on Google Season of Docs.

proposal-selection.md

Timing will typically align with the Season of Docs schedule.

@flicstar :
Does this mean the program itself, or just the time frames for each working phase?
It doesn't make sense (unless I'm missing something) that our project should align proposal work with a completely separate program run by another body. Perhaps the intention with this phrase was more about "We use the SoD as a guide for the different phases of work in a proposal, including how long each might typically run for". Or whatever. And then the URL should probably point to the timeline rather than the home page. No but that won't work because the timeline specifies a date.
I'm tempted to remove this line altogether. If we want proposals to adhere to a certain framework (about timing) then we should create our own and publish that on a separate page.

@jaredmorgs:
+1 to removing if this line is trying to suggest that we only sponsor projects through Google Season of Docs.

@jaredmorgs
Happy to record this as an action but let it release as part of the initial alpha cut of the proposal selection guidelines.

@mgan59
I feel like GSoD should be a separate from this in some-way as the primary goal for Proposal-Selection should be for our community-contributors and GSoD is the edge-case?

@camerons
Copy link
Member Author

We should consider this review comment:

In proposal-selection.md

  • You will need a mentor before you get an application approved.
    @jaredmorgs
    This isn't technically true in GSoD. You get a mentor after you are accepted as a GSoD sponsored participant.

@camerons
Copy link
Member Author

Consider this comment in proposal-selection.md:

  • Community decides if the proposal is worth backing, and locks in if it is.
    @Loquacity
    Might need to be more specific about what "locking in" means here.

@camerons
Copy link
Member Author

Consider this comment in proposal-selection.md

  • Where applicable, guidance on budget will typically be based on the stipend amounts used by Season of Docs (20-30 hours per week x 3 months, or equivalent effort spread over 6 months). This will be referenced from the Request for Proposal.
    @jaredmorgs
    Again, very GSoD specific here.

@camerons
Copy link
Member Author

Consider this comment in proposal-selection.md

  • Payments should be correlated to milestones as github tasks.
    @Loquacity
    Does this mean that the payment is recorded in a github issue, or that it's linked to successful closure of a specific issue, or ... ?

@mgan59
yeah this is an interesting one... assuming payments are in the open-collective, and question there on getting them connected back to this.

I do think it makes sense for us to create a standard milestone concept across all our repos. I typically organize my milestones around Fiscal-Quarters as that is how I do my RoadMap planning.

@camerons
Copy link
Member Author

Consider this comment in proposal-selection.md

  • When a milestone is reached:
    • The implementor should comment on the milestone task, asking the mentor for review.
      @Loquacity
      lol @ "implementor", I keep reading it something like "dementor" 😂 Perhaps it would be a good idea to define these roles somewhere? I'm not 100% certain if an implementor is the person doing the work (mentee?) or some other person in the community.

@jaredmorgs
If this is quick to fix then I'm 👍 otherwise leave it for the next iteration of this document IMHO.

@mgan59
contributor ?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant