[GSoC] Agile approach to project mentoring

[Alex Herbert <al...@gmail.com>]

The GSoC guidelines for students writing a proposal [1] is to use the 
guidelines or templates of the organization. It then states that certain 
elements will improve chances of a proposal including in Deliverables:

"a brief, clear work breakdown structure with milestones and deadlines.

... start by producing some kind of white paper, or planning the project 
in traditional Software Engineering style."

AFAIK there is no template we are adhering to under Commons GSoC. For 
most of the GSoC projects I have seen on Commons it is apparent that the 
targets are very flexible. Perhaps some sort of agile software 
engineering style is suitable here. At least when I did SCRUM [1] the 
idea was a daily 15 minutes stand-up to discuss issues and progress with 
the aim of completing deliverable iterations within a week or fortnight.

I can certainly see an agile method as a way to work with a mentee when 
the expected contributions to the codebase can be partitioned into 
independent tasks.

The first iteration may involve getting familiar with the code, running 
tests, building javadoc, etc. Basically understanding all the 
deliverables that a release of a commons component outputs.

After that each iteration can be the development and test and PR of an 
addition to the commons project. If the iteration is not quite an 
encapsulated PR then some measurable state on a topic branch (such as a 
tagged milestone). Being agile leaves the plan open to change and 
flexible to adapt to the interest of the mentee.

As for the agile workflow, I am not sure how a remote stand-up would 
work given time zones but one to think about. Perhaps an open Google 
doc/spreadsheet where new items are added, discussed and resolved. This 
would have to be checked daily by team members. Major issues can then be 
promoted to an on-line discussion. (Any experience with working in a 
geographically remote agile group would be useful to know.)

Opinions are welcome.

Alex


[1] https://google.github.io/gsocguides/student/writing-a-proposal

[2] https://en.wikipedia.org/wiki/Scrum_(software_development)



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [GSoC] Agile approach to project mentoring

[Gilles Sadowski <gi...@gmail.com>]

Hello.

Le jeu. 28 mars 2019 à 16:43, Alex Herbert <al...@gmail.com> a écrit :
>
> The GSoC guidelines for students writing a proposal [1] is to use the
> guidelines or templates of the organization. It then states that certain
> elements will improve chances of a proposal including in Deliverables:
>
> "a brief, clear work breakdown structure with milestones and deadlines.
>
> ... start by producing some kind of white paper, or planning the project
> in traditional Software Engineering style."
>
> AFAIK there is no template we are adhering to under Commons GSoC. For
> most of the GSoC projects I have seen on Commons it is apparent that the
> targets are very flexible. Perhaps some sort of agile software
> engineering style is suitable here. At least when I did SCRUM [1] the
> idea was a daily 15 minutes stand-up to discuss issues and progress with
> the aim of completing deliverable iterations within a week or fortnight.
>
> I can certainly see an agile method as a way to work with a mentee when
> the expected contributions to the codebase can be partitioned into
> independent tasks.
>
> The first iteration may involve getting familiar with the code, running
> tests, building javadoc, etc. Basically understanding all the
> deliverables that a release of a commons component outputs.
>
> After that each iteration can be the development and test and PR of an
> addition to the commons project. If the iteration is not quite an
> encapsulated PR then some measurable state on a topic branch (such as a
> tagged milestone). Being agile leaves the plan open to change and
> flexible to adapt to the interest of the mentee.
>
> As for the agile workflow, I am not sure how a remote stand-up would
> work given time zones but one to think about. Perhaps an open Google
> doc/spreadsheet where new items are added, discussed and resolved. This
> would have to be checked daily by team members. Major issues can then be
> promoted to an on-line discussion. (Any experience with working in a
> geographically remote agile group would be useful to know.)
>
> Opinions are welcome.
>
> Alex
>
>
> [1] https://google.github.io/gsocguides/student/writing-a-proposal
>
> [2] https://en.wikipedia.org/wiki/Scrum_(software_development)

First remark is that we'd need more mentors in order to form a minimal
"Scrum" team. ;-)

Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org