Re: [Outreachy] Git remote whitelist/blacklist

[elena petrashen <elena.petrashen@gmail.com>]

Hi everyone,

I think I will submit the application as it is now, but still
it would be great to get feedback on it, as I don't think
there was no reply because everything was perfect :(

Thank you! And have an awesome weekend.

On Thu, Mar 24, 2016 at 5:50 PM, elena petrashen
<elena.petrashen@gmail.com> wrote:
> Hi,
>
> I'm thinking of applying to Outreachy program this round with Git
> and the project I'm really interested in is "Git remote whitelist/blacklist"
> project (http://git.github.io/SoC-2016-Ideas/).
> I have drafted the description/timeline for this project
> and it would be great to get feedback/suggestions.
> (I'm actually a bit confused about the scale of this. The
> Outreachy application doesn't ask for "proposal" in the way
> GSoC seems to, but merely requests "details and the timeline",
> so I'm not sure whether the shorter description of what's planned
> is expected or should I go deeper in detail. I apologize if I
> chose a wrong approach.)
>
> Thank you!
>
>>> What project(s) are you interested in (these can be in the
> same or different organizations)?
> My preferred project to work on is Git remote whitelist/blacklist
> project listed on http://git.github.io/SoC-2016-Ideas/. I'm really
> interested in doing this project as I think this kind of effort is
> really important: I recently started using git myself, and sometimes
> I was really scared to push something to the location I was not
> supposed to push to. I would really appreciate the opportunity in
> participating in making git a bit more newbie-friendly.
>
>>> Who is a possible mentor for the project you are most interested in?
> Lars Schneider
>
>>> Please describe the details and the timeline of the work you
> plan to accomplish on the project you are most interested in (discuss
> these first with the mentor of the project):
> The goal is to provide a safer environment for newcomers to Git to
>  enabling the possibility to modify git config, adding there "allowed"
>  and "denied" remotes for pushing. Code, tests, and documentation
>  are to be created.
>
> Timeline:
> 0. Analysis
>   Apr 22 - May 22 - studying the current code and drafting the
> implementation proposal
> 1. Design
>  a. May 22-June 1 - discussion with the mentor regarding the task,
> presenting the approach and amending it per mentor's feedback
>  b. June 1st-June 15th - communicating with the community
> regarding the suggested changes and agreeing on logic, scope
> and format of changes.
> 2. Development
>  c. June 15th-July 1st - submitting code for the first basic version,
> amending it according to the feedback
>  d. July 1st - July 15th - extending the code to cover all of the
> agreed scope
>  e. July 15th - Aug 1st - finalizing full coverage with tests and
> documentation
> 3. Evaluation
>  f. Aug 1st - Aug 23rd - adding nice-to-have features and other
> suggestion by the community