
How do you manage your project? - resotto
I know GitHub functionalities such as Labels, Milestone, and Projects(Kanban).<p>However, I don’t know how to manage issues dependencies (for instance, there are three issues A,B,C and they must be done in the order B-&gt;C-&gt;A) and detailed schedules like Gantt Chart.<p>So please give me your opinions.<p>Thank you.
======
PragmaticPulp
Team environment, or individual project?

The first rule of project management is to keep it as simple as you can get
away with. Don't overcomplicate anything until absolutely necessary.

> I don’t know how to manage issues dependencies (for instance, there are
> three issues A,B,C and they must be done in the order B->C->A)

In the ticket for C, note that it depends on B. Link to B at the top of the
description. Anyone reading the ticket should immediately see that B must be
done first, and will click through to it. Repeat for A's dependency on C. Keep
it simple.

> detailed schedules like Gantt Chart.

Unless you have perfect estimation skills and you can 100% scope your project
from the start, you it's not realistic to put all of your tickets on to a
Gantt chart. You'll find that the Gantt chart goes out of date within weeks or
even days.

Gantt charts are best reserved for high-level goals and milestones. For
example, you could plan to work on B on week 41, work on C on week 42, and
then work on A on weeks 43-44 with a milestone for completion of this group at
the end of week 44.

However, the Gantt chart isn't all that useful for dependencies within a
single, contained project. It becomes more useful to view dependencies across
teams and projects when you can allocate more people to tasks as necessary to
unblock the critical path. If you're just working on a single project, the
Gantt chart often simplifies to a basic estimation calendar, so use a base
calendar instead.

~~~
resotto
Thank you for your replying.

It is for team environment.

Yeah, I agree with you.

I have experienced mid~long period project and struggled with them so I asked
this topic.

------
resotto
And if you want tools for managing project, what is it?

------
Jugurtha
\- What's causing the most trouble for the users in terms of frequency and
severity?

\- Which one could have the biggest impact and how much work to implement it
(hard/long)?

\- Which one if done will unlock a graph of possibilities for features to
come, or other issues becoming irrelevant once that's done?

\- Are these issues materializations of the same underlying problem?

Example: our users were _constantly_ competing for resources to train their
models with notebooks in a tragedy of the commons way. GPU/RAM, etc. Notebook
users are familiar with "OOM" errors. You start training using a notebook,
someone else does the same, bam!.

The thing to do was clear: schedule notebooks[0]. It doesn't have to be fair
queuing, even FIFO does the job. Just put the notebooks in a queue and execute
them sequentially. No priority.

The issues might have said "Out of Memory" errors, and a naive approach would
be to simply add resources but is that really the underlying problem? No.

Once you have notebooks running asynchronously, it opens a whole new graph of
possibilities and makes it easier to do things properly, like leverage a
proven workload manager. The limiting step was to de-couple the intent to
execute, from the execution, and wrap it in a request. Now you can re-run it,
delegate it to a more powerful node, etc.

One other issue it solves is something notebook users are familiar with, too:
you can't access the results of a computation if you close your
browser/tab/computer. If the connection between the kernel and the front is
lost in Jupyter notebooks, the computation continues, but the results don't
make it to the front. You could have a training job that takes hours, if the
connection is lost, so is your result. Notebook users solve this by saving
their model to disk, but notebook users aren't using notebooks just for that.
They want graphs and visualizations in the notebook too, or else they would
have just used a script. Also, that is possible but we do automatic
model/parameter logging so our users don't bother with that, so they could
always click on "Deploy" and their model is deployed.

Focusing on scheduling notebooks solves that. Now even if users closed their
laptops, or the connection was lost, the result of the notebook would still be
there.

Then we went further: displaying the results of the run outside of Jupyter,
and now you can show a client the result of the work, and you can discuss it.

So that was an example of handling an issue that "fixes" a problem like
crashes, and indirectly unlocking possibilities.

Now examples of handling issues/tickets implementing a "feature" where there
are no crashes: users worked in tandem, and sometimes asked assistance and we
helped them troubleshoot their code. One pattern is they shared "screenshots"
of the code. We already had a sharing functionality with which they could
simply share their notebook with another user, and the user could edit.

We added near realtime collaboration[1] to notebooks so several people could
work together on the same notebook, see what everyone else was editing,
following your cursor while you were doing so. Being able to work on the same
document clearly simplified things for users who were not proficient with Git,
which is also why we have added multiple checkpoints[2], as the default was
one checkpoint.

So, a question to ask is "should we do this?", and then look at the
tickets/issues that have high impact. Some of them will be harder to implement
than others, and you have to balance your allocation, but at least you'll do
it on something that matters to users.

[0]: [https://iko.ai/docs/notebook/#long-running-
notebooks](https://iko.ai/docs/notebook/#long-running-notebooks)

[1]:
[https://iko.ai/docs/notebook/#collaboration](https://iko.ai/docs/notebook/#collaboration)

[2]: [https://iko.ai/docs/notebook/#multiple-
checkpoints](https://iko.ai/docs/notebook/#multiple-checkpoints)

~~~
resotto
what are you talking about?

~~~
Jugurtha
OP's question was about how to manage a project and and how to decide which
order to do issues that are interdependent in.

The reply was whether the issues needed to be resolved, and gave a set of
questions to ask to find out what to work on and what _not_ to work on, and
gave examples from an actual real world project in both situations [fix a
problem / add a feature].

In other words: how to manage a project and how to decide what to do and what
not to do.

Which part is confusing?

~~~
resotto
I got it. Thank you.

~~~
Jugurtha
My pleasure.

