Hey guys, thanks for doing this! We do need to make changes to how we release software. Let me make some comments below.
On Sat, Aug 3, 2013 at 2:22 AM, Benjamin Tissoires < [email protected]> wrote: > Hi, > > after the Q&A with the board of this morning session, I discussed with > Spider, and we thought that instead of having _one_ person in charge > of aggregating all the changes once the release is done, we could > spread this work among all of us. > > So, here is the formal proposal we wrote: > > > Will you ratify this with the rest of the release team? > Change proposal: > The basic idea is that we shouldn't overload maintainers, but we > should also not require a heroic effort by single person. > Effort needs to be spread out amongst many people, and the work > needs to be integrated in our normal release practices. > > Yes, this is a good idea. Having a group would definitely help. Do you have people in mind to do this? > Just because you are maintainer, doesn't mean you must do it, you > only have to make sure someone does it. It could be required to be > documented as part of patch submitting or code review, the way tests, > documentation and other things are related to a feature. > > That's cool, I especially feel that this information must also be shared with the documentation team. Kat was telling me that they would know about new features after the fact. Documentation is especially important for me and I would like to make sure that we are making sure that this information especially user visible visual changes are properly communicated by the release team. > > * All module maintainers should ( in the release cycle ) be clear > about what features are added as new and removed. > > This can involve rationale for the change ( Why did we remove > transparency from the terminal? ) but that is not a must. The > Marketing team can always ask the maintainers for details. > > > What means do we have to challenge a feature removal? While I respect a maintainer's decision, I'm interested in keeping good relations with our community. Sometimes there are things removed that would be very challenging to defend. > * The major changes should be documented between alpha and beta? ( > but always before UI freeze ), thus giving us ~3 months before "proper > release" to do user interaction and communication on forums, slashdot > and other things. > > Sounds good. > * It is the Release Teams responsibility to ensure that all > modules _do_ these "feature changes", but it is the module owners > responsibility to _write_ them or make someone write it for them. > > If they do not.. what would be the consequences? Do we delay release? > * Marketing team should follow these changes and work from them to > avoid major user hostility that may be caused by missing features. > > Sounds good. > * Marketing should work on this to inform users/ slowly drip > "changes" to public attention _before_ the code drops as "stable". > > We should provide suggestions as well. > ( Note that just because this is documented, the code doesn't need > to be removed at this time, but the _intention_ should be very clear. > ) > It's free software, we do change our minds at times. > The bikeshed should be green. > > Sure. I see that you've put some thought into this and I thank you for that! I do have some other changes that i think would help. We are contantly criticized when extensions break. I would like ot make sure that we have an image available for people to download and try out. There should be at least a week of user testing. We should make sure that things work for the most part. sri > > > Cheers, > Benjamin & Spider > -- > https://mail.gnome.org/mailman/listinfo/board-list > > From time to time confidential and sensitive information will be discussed > on this mailing list. Please take care to mark confidential information as > confidential, and do not redistribute this information without permission. >
-- marketing-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/marketing-list
