This was part of "[DISCUSS] RC1 build" but seems like it might need to be discussed separately.
> 1. do not work on a change without a ticket. > > This can be considered somewhat unnecessary with regards to how github > works, more specifically a PR in github **is a ticket** and since we use > github for both pull requests and tickets this distinction can be > considered somewhat arbitrary. > The reason this is necessary is because people coming into the project looking for things to work on are going to look at tickets not pull requests. In order to keep a handle on what is being done we need to have issues, and we need to work to the issues. If you work on a change and I work on the same change and neither of us has a ticket open then we have no coordination. In addition, anyone else that is interested in the outcome or design of the ticket does not have a place to a) discover the work is being done or b) contribute to the discussion/work. Not working to tickets makes the process more opaque. > On a related note, the reason why people worked on features without > creating issues first is simply due to velocity. If we had to go through a > formal process we would have achieved a fraction of what we have done > currently. I would suggest the most appropriate time to introduce new > process would be after the first release, not now. Its already been both > communicated and demonstrated multiple times that the current development > process of Pekko is highly tailored to the unique scenario we are in (i.e. > first release after a hard work) and that it does need to change, but doing > so now in my opinion would introduce a real risk of slowing things down > which is the exact opposite of what we want to do now. How much time does it take to open a ticket if you want to do some particular piece of work? Does it slow you down? Sure 5 minutes to open a ticket and then you are off and running. You've got documentation of the issue, you've put yourself out there as a contact for the resolution of the issue. You can point to the issue on the mailing list. You have a place for discussion about the issue. If there is not documentation for what was done. If there is not a trail discussing what needs to be done. If that trail is not searchable. If that trail is not immutable. If there is not opportunity for new contributors to easily discover where they can contribute and to contribute to the project then the probability of getting the release approved by the IPMC is slim. I am not saying Pekko has to meet all the items listed above, but a preponderance would be good. I understand the original need to get things in shape quickly. But the team needs to understand that the time for speed may be passed and the time to show that Pekko believes in Community over Code is upon us. From what I have seen, Pekko works. It can be used to replace Akka in multiple environments. Yeoman' work has been completed, and the team is to be congratulated for that. But now turn attention to the processes that Apache puts to the fore. Community over Code is not just a slogan, Pekko needs to work to be more transparent and more accessible. > > 2. make sure the ticket is associated with the milestone. > > This is already being done, at least for tickets/pull requests that are > relevant to a milestone. See https://github.com/orgs/apache/projects/ and > https://github.com/apache/incubator-pekko/milestones I wanted to make it clear that we need to focus on tickets that are in the milestone and leave the others alone. When added to the above "No work without a ticket" it means we are working to get the milestone closed. > 3. when you are working on a ticket, assign it to yourself. If you can > not assign it to yourself, post a note on the dev mailing list with a > subject prefix of [ACCESS] noting the ticket that you do not have access to > and then add a comment to the ticket indicating that you are working on it. > > Github doesn't allow you to assign tickets if you are not a maintainer > (which for Apache projects means comitter). I have noted in the past that > we need to be a lot better about assigning in general (this has been noted > multiple times) however I will raise the some points raised in response to > point number 1 here. Collaborators can assign issues, label them, and close issues. It's configurable via .asf.yaml. So we can add non-committers as collaborators and they can begin to work within this framework. An example can be found in the Air Flow project [1]. This can be a good first step to welcome contributors that may become committers later. > > > 4. any change that is not a simple break/fix should be discussed in the > dev mail list with the subject prefix of [DISUCSS]. > > What is the mentality behind this? I strongly disagree with making such a > rule, we shouldn't be preventing people from making contributions even if > they are not focused on the current milestone/release candidate. I don't > have any issue in freezing the repository during a release process but this > is one step too far. Its especially damaging in the case of Pekko because > since we have made an agreement that version 1.0.x doesn't introduce new > features, people have been making pull requests for new features over time > with the expectation they will get merged later. Such a rule send a very > negative signal to potential contributors. > Sorry, I was not clear here. I meant this to apply to any ticket in the current milestone [2]. As you state the goal is to release without change, so this is to enforce that within the current milestone. I do not propose that we not accept any improvements as fixes for CVE for example should be accepted -- after proper due diligence. Claude [1] https://github.com/apache/airflow/blob/main/.asf.yaml#L73 [2] https://github.com/apache/incubator-pekko/milestone/1
