In-development process needed

Development
#1

We’ve got policies and tooling to go with it that relates to the transition from the end of one development cycle to the start of the next. Unfortunately, we don’t really have anything in place for during the development cycle. I think we have kind of organically done what has needed to happen, but I’ve also noted cases where we have missed things. I think if we were a much bigger team we wouldn’t need this, but we’re not.

That said, I think that putting something in place would allow us to be more proactive, allowing us to better assess the scale of the workload and thus, better delegate it to the right contributors. I don’t claim to know what the right thing to do is, so I am reaching out to the community for input.

That said, here are some areas where I know we need to pay attention to:

  • Merges from Debian.
    • I’m currently working on a script to run through our packageset and then dig through MoM to figure out which packages are problematic, if any. I’ve affectionately named it lubumom.sh.
  • Upstream development, both in terms of new commits as well as release planning.
    • The incoming wiki page intends to cover instances of interesting (especially bug-fixing) commits.
    • There is really nothing to cover release planning outside of this.
    • We should also be regularly be participating in discussions in issues and other forums so that we can make sure that our users concerns are represented.
    • The big ones here are LXQt and Calamares, so that should be pretty simple.
  • The new code needed wiki lists tasks that really should require us and not upstream to generate new code.
    • In some cases, upstream may decide to implement solutions, so we should watch for that.
    • Regardless of upstream, this should always be reviewed as there a chance one of the issues could get resolved.
  • The unassigned/scopeless meta-task should always be reviewed as some of those may be more feasible given current circumstances.

Right off the top of my head, I’m kind of wondering if it shouldn’t be someone’s task to review all of these things weekly and present the results to the meetings. That person could rotate weekly so as to distribute the workload. I think giving someone the responsibility will better ensure that these things will get done.

Thoughts?

3 Likes
#2

I appreciate that you made this post @wxl, I think having this discussion in the open forum is good. I don’t know what the right thing to do is either but together I think we all have valuable input to the conversation.

That is cool, I like it.

This is definitely a case of having more eyes on it is better. I try to keep close tabs on Calamares but it is a very active project, the same goes for the LXQt stuff. This isn’t a overly technical task it is just more a matter of watching the upstream activity and delivering a TL;DR report to the rest of the team.

I think giving ownership of this to someone (or an established rotation) is a very solid idea. I think we need to develop an outline of things we need to have covered from week to week so that when a meeting happens we can run down the list.

We went a long time where we didn’t have weekly meetings, now that we have them rolling again I think this would take it to the next level.

2 Likes
#3

All of our discussions really should be. To be fair, they already are, but I’d say this is far more approachable than IRC or Phabricator to a lot of folks. Additionally, I think sometimes we have a tendency to decide to do X without much discussion on it. We’re always open to changes, but that may not be so obvious. That said, I think if we can get into this habit a little bit more or at least the habit of encouraging discussion on development, that would be a big plus.

Maybe an even better idea (because overwhelming people is not good) would be to give particular items to a person or rotating cast and collectively all of the people involved would cover all of the items we need. Having one person spend hours of time is probably less sustainable than several people spending a few minutes.

This is exactly what we need and is probably the best place to start. I’m going to try to experiment with the wiki feature to see if maybe one of the posts (the next one) can be editable by all to provide that list.

Update: indeed one can make a single post within a topic a wiki, so the next one is editable by all. Please review, change, and discuss as needed.

#4

NOTE: this post is a wiki everyone can edit, so feel free to add or change.

Items needing weekly review/reports

  1. State of Debian merges
  2. State of upstream development (mostly LXQt, Calamares)
    1. Milestone/release updates
    2. Policy change/news
    3. New features
    4. Discussions that affect us
    5. Fixes for downstream bugs
  3. Bugs in our packageset
    1. Which are hot?
    2. Which need triage/help?
  4. State of testing
    1. How are things progressing?
    2. What bugs are we seeing?
    3. Is additional help needed?
    4. Is there any special testing that needs to happen?
  5. Tasks in Phabricator
    1. Which need triage?
    2. Should any be added to or dropped from milestones?
    3. Should any be closed?
    4. Can any of the unassigned/scopeless tasks be assigned or scoped?
  6. Pull requests in Phabricator
    1. Are there any waiting on review?
  7. Support requests
    1. Are there any unsolved/difficult issues that need help?
  8. New code needed
    1. Are these all still relevant?
2 Likes
#5

I am in full support of this. Shall we start doing weekly posts using this outline so that we can track this for our meetings?

1 Like
#6

Ohh that smells a lot like having an agenda ahead of time. I like that!

1 Like