Christopher Baines <
mail@cbaines.net> ezt írta (időpont: 2019. szept. 6., P, 8:55):
Gábor Boskovits <boskovits@gmail.com> writes:
>>
>>
> After discussing this with Ricardo and Ludo, it seems that the way forward
> would be to
> get the project under the Guix umbrella, like it was done for cuirass. If
> you do not oppose,
> I would like to ask Ludo to file a request for a sub-repository to
> savannah-hackers, so that
> we could move the code there. Wdyt?
That works for me :)
I guess this kind of thing relates to the "Project Contribution
Information" part of the proposal. I think there's some other bits of
preparation to do for this, like:
- Making sure the service is actually running publicly somewhere (maybe
milano-guix-1 if that's back working, maybe somewhere else if not)
- Generating a small sample database that can be used for local
development
- Writing some step-by-step instructions for running the service
locally
I'm guessing that it would be ideal to have all this done by the 24th of
September, but it would be good to clarify that?
It would be nice to have it by the 24th.
I guess we can skip the publicly running instance, if we must.
> Also, should you need any help in finding out what to do with the TODO
> sections, we could arrange
> an appointment on IRC. How does that sound?
Regarding the "Internship Tasks", I have some ideas here that I haven't
written up yet, I also just need to do some more thinking and
investigating. I'm sure if I spend some time looking, I can find some
rough edges in the functionality that would make good small tasks.
I'm not particularly clear on the timeline for this though, does this
need to be done by the 24th of September, or sooner?
The proposal is just a rough project outline, which can be refined later,
but should be in its final form by the 24, so that applicants reading it
can have a rough estimate of the timeline, and of the milestones.
Having starter tasks defined is actually outside the scope of Outreachy, but
an applicant must have a valid contribution to the project by the time of intern
selection. These are also very helpful for you to know what it would be like to with
a given intern. I would say there is no strict timeline on this, but very much reduces
the communication overhead at the beginning, thus it is easier for you, and more
attractive to the applicants. Wdyt?
> Also, Ricardo brought to my attention the following things, that could help
> things go more smoothly, while
> keeping the intern motivated:
>
> 1. keep some low hanging fruits, so that applicants can make their first
> contribuitons,
> 2. divide the project to stages, and set milestones, so that the individual
> stages can be evaluated independently,
> 3. try to pinpoint a preferred outcome (Ricardo paraphrased this as the
> mentor should know what is to be done).
> (I thank Ricardo for helpful comments. All errors remain mine.)
I'm hoping that most of this will fall out of working more on defining
various tasks.
The preferred outcome in my mind is twofold:
- Extend the database schema to support storing translations for
package synopsis and descriptions
- Add initial support for translating strings within the Guix Data
Service web interface
Looks good to me.
Some beginning, and sub-tasks need outlining, and once that is more
understood, hopefully we'll be in a better place to check if the above
is a reasonable goal. I think it would be also good to add some stretch
goals as well.
Yes, stretch tasks also make sense. Later the applicants will also be asked to
a timeline. It is nice if they plan some spare time in their schedule, so that they
can stay on deadline, and be less stressed about it.