Re: Release change proposal
- From: Benjamin Tissoires <benjamin tissoires gmail com>
- To: Sriram Ramkrishna <sri ramkrishna me>
- Cc: GNOME Foundation Board <board-list gnome org>, release-team gnome org, GNOME Marketing List <marketing-list gnome org>, spider gnome org
- Subject: Re: Release change proposal
- Date: Sat, 3 Aug 2013 16:55:17 +0200
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 <sri 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 tissoires 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]