Hi Sri, (adding in CC the release team too).
I just had a quick talk with Bastien, and actually he told me that this process is already existing, but is maybe just too late in the process. During the release, the release team ask every maintainers for a list of changes. Maybe we could just move this request a little bit earlier (UI freeze, or even earlier) so that documentation and marketing could have a little bit more time to work on the features. (Sorry, I'm new to the Gnome development process, so I don't know all of the subtleties) Anyway, here are my answers: On Sat, Aug 3, 2013 at 2:55 PM, Sriram Ramkrishna <s...@ramkrishna.me> wrote: > 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 > <benjamin.tissoi...@gmail.com> 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? Sure, I think that we should involve more people (release and even maintainers) and not impose this kind of decision. Our intent is to make maintainers understand that this will benefit them from many aspects (better documentation, better marketing, avoid flame-wars, and improve communication). I actually think it may also lower some of their work because they won't have to do marketing things later or defend themselves after the release. > >> >> 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? > Actually we thought at the maintainers of the projects. They are the person who know the best their own project. If they do not want to do it, for any reason, they can still ask someone else to do it (or even better, someone else can volunteer to do it). > >> >> 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. > Yep, it has to be public at some point and this way, documentation team can also benefit from it. >> >> >> * 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. I don't think we should challenge a feature removal. I'm sure that there is always a good reason to remove a feature. A simple answer like "this piece of code is totally unmaintainable, so we remove it so that we can provide a better user experience" is totally acceptable. To my mind, it's all about communication and maybe we can re-add this feature with a proper implementation later. The point of giving new and removed features earlier in the process is a way to prepare users what they will have in few months, without hiding things. > >> >> * 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? > Can we really speak about "consequences"? (sorry if I'm taking this the wrong way). We should encourage maintainers to do that and explain to them the benefits that they will have, including a better documentation and less user frustration for instance. >> >> * 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. You should, but if this is happening at UI freeze (late in the cycle), then this might be a little late. Anyway, this could be proposals for the next cycle :) > >> >> ( 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! > It's great to see some good feedback. Thanks. > 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. > Again, I'm new to the community, but isn't it the role of the alphas and betas? I just want to understand the real problem. But definitively wide user testing is a good thing and should be pushed forward. Cheers, Benjamin -- marketing-list mailing list marketing-list@gnome.org https://mail.gnome.org/mailman/listinfo/marketing-list
